PI60479: SHARED QUEUE MESSAGES LEFT IN UNCOMMITTED STATE FOLLOWING STOP QMGR MODE(FORCE)

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Shared queue messages left in uncommitted state following STOP
  QMGR MODE(FORCE)
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 7 *
  *                 Release 1 Modification 0.                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: Messages left uncommitted on shared     *
  *                      queues following STOP QMGR MODE(FORCE). *
  *                      In rare cases, messages can be          *
  *                      incorrectly backed out onto shared      *
  *                      queues after being successfully got.    *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  A unit of work involving messages on shared queues was in the
  process of being backed out due to an MQBACK call when STOP QMGR
  MODE(FORCE) was issued.
  CSQESYNC was part way through backing out the eTRQS/eTROP
  control blocks representing the shared queue actions performed
  by the uow, and had performed an execution unit switch to wait
  for a required log update to complete, however the STOP command
  caused it to be resumed and abended 5C6-00E50013 (as expected in
  this situation).
  However, errors in recovery processing for CSQESYNC did not
  allow for the eTRQS chain having only been part processed.
  This meant that any eTROPs that had not been processed at the
  time of this expected abend were not processed by recovery
  processing, leading to the messages they represented remaining
  in an uncommitted state on the queue.
  eTROPs associated with eTRQS blocks that had already been
  processed were processed a second time during thread termination
  processing. In rare timing cases, the messages these TROPs
  represented could be got on another queue manager between the
  two backout attempts, causing the message to be incorrectly
  returned to the shared queue.
  

Problem conclusion

• CSQESYNC's recovery routine has been corrected to process any
  unprocessed eTRQS/eTROP control blocks, and ensure that such
  eTROP blocks are only processed once in the event of STOP QMGR
  MODE(FORCE) causing an abend during backout processing.
  100Y
  CSQESYNC
  

Temporary fix

• *********
  * HIPER *
  *********
  

Comments

• ×**** PE16/11/01 FIX IN ERROR. SEE APAR PI71577  FOR DESCRIPTION
  

APAR Information

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

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

  PI60773 UI38191

Modules/Macros

• CSQESYNC
  

Fix information

• Fixed component name

  WMQ Z/OS V7

• Fixed component ID

  5655R3600

Applicable component levels

• R100 PSY UI38191

     UP16/07/06 P F607 ¢

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.