PM60235: DURING WSAS ASYNC MESSAGE CONSUME THE WRONG BLOA IS USED BY THE CONSUMER

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• When an MQCONN is issued in WAS for the qmgr name, optimisation
  code in CSQBWSTB returns the bloa for the current TCB if one is
  found, rather than going to CSQBCON each time.
  
  If we're running on an async consume TCB, this returns the async
  consume (dummy) bloa, rather than the bloa of the owner of the
  async consume.
  
  This is different from the bloa CSQBCON returns, and means the
  wrong bloa is used.  MQ calls shoulld not be made on the dummy
  bloa, so this may cause problems.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 7 *
  *                 Release 0 Modification 1 and Release 1       *
  *                 Modification 0 using WSAS.                   *
  ****************************************************************
  * PROBLEM DESCRIPTION: During WSAS async message consume the   *
  *                      wrong Hconn may be used by the          *
  *                      consumer.                               *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  The JMS code on z/OS uses the RRS interface to connect to WMQ
  when running under WSAS.  To deal with the possibility of JMS
  objects being moved from one thread another, every WMQ call is
  preceded by an MQCONN to ensure that the TCB we are currently
  running on has a connection to the queue manager.  If we already
  have a connection, stub CSQBWSTB optimizes MQCONN processing to
  avoid the need for a LINK to CSQBCON on every call and returns
  the Hconn (address of the BLOA ) for the current TCB.  The
  problem is that if we're running on an async consume TCB, this
  will return the async consume (dummy) BLOA, rather than the BLOA
  of the owner of the async consume.
  
  This is different from what CSQBCON does, and means the
  subsequent WMQ call using this Hconn is running on the wrong
  BLOA.
  

Problem conclusion

• The code has been changed to return the correct BLOA in this
  situation.
  010Y
  100Y
  CSQBWSTB
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  UK92049 UK92050

Modules/Macros

• CSQBWSTB
  

Fix information

• Fixed component name

  WMQ Z/OS V7

• Fixed component ID

  5655R3600

Applicable component levels

• R010 PSY UK92049

     UP13/04/10 P F304

• R100 PSY UK92050

     UP13/04/04 P F304

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.