PH64100: ISSUE WITH MQGMO_WAIT OR MQGMO_SET_SIGNAL MQGET ON A SHARED QUEUE WHEN SYSPPSTDPTHSQ IS ENABLED

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• The customer has the "SYSPPstDpthSQ" service parm enabled on
  two queue managers on a QSG which is causing an issue with
  MQGMO_WAIT or MQGMO_SET_SIGNAL MQGET made to a shared queue
  
  If this service parm is enabled, then CSQMLTR0 only posts as
  many get waiters as there are messages, which reduces the
  number of 'empty gets'. There is a logic error identified with
  this parameter, where an internal bit is turned off, and future
  get waiters are not posted. This means that when the next batch
  of messages arrives, it won't invoke CSQMLTR0, which queries
  the current depth of the shared queue, and the message will not
  be consumed.
  .
  Additional Keywords and Symptoms:
  CURDEPTH
  

Local fix

• Contact IBM Support for detailed instructions on how to turn off
  the SYSPPstDpthSQ service parameter.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of IBM MQ for z/OS Version 9       *
  *                 Release 2 Modification 0,                    *
  *                 Release 3 Modification 0 and                 *
  *                 Release 4 Modification 0.                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: When the service parameter              *
  *                      'SYSPPstDpthSQ' is enabled, MQGET calls *
  *                      to a shared queue using the options     *
  *                      MQGMO_WAIT or MQGMO_SET_SIGNAL may not  *
  *                      receive messages after an MQPUT to that *
  *                      shared queue.                           *
  ****************************************************************
  If the 'SYSPPstDpthSQ' service parameter is enabled, the code
  which handles the posting to every MQGET call of shared
  queues only posts as many waiting MQGETs as the initial number
  of messages in the queue in order to reduce the number of
  'empty' gets. However, if the queue were to be empty at any
  point after the get-waiters were started, the MQGETs that were
  not posted would be skipped and not posted even if the queue
  becomes non-empty again. As a result, only certain queue
  managers in the queue sharing group receive messages, while the
  others do not.
  

Problem conclusion

• The code has been changed to do an extra post to the waiting
  MQGET calls even if the depth of the queue is 0 when the
  'SYSPPstDpthSQ' service parameter is enabled.
  

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:

  UI99370 UI99371 UI99372

Modules/Macros

• CSQMLTR0
  

Fix information

• Fixed component name

  IBM MQ Z/OS V9

• Fixed component ID

  5655MQ900

Applicable component levels

• R200 PSY UI99372

     UP25/01/07 P F501

• R300 PSY UI99371

     UP25/01/07 P F501

• R400 PSY UI99370

     UP25/01/07 P F501

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.