PH44959: MQ ABEND5C6 00C91200 IN CSQICDSQ 22/03/21 PTF PECHANGE

APAR status

• Closed as program error.

Error description

• MQ Development finds there ends up being, effectively, two
  requests for QMGRs to delete an object. For example, in a QSG
  we have QMGR1 and QMGR2. On QMGR1 a queue is deleted which will
  send a kiss-and-tell to QMGR2 also telling it to delete the
  queue, hence the first request. Meanwhile, QMGR2 is also doing
  similar work and if conditions are right then MQ will send a
  broadcast (kiss-and-tell) to itself, hence the second request
  to delete the object. This occurs due to a small timing window
  between the first and second requests, hence the second request
  is also processed. However, the second request will result in
  the 5C6-00C91200 abend as the object has already been deleted,
  hence why the abending MQ cannot locate it.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of IBM MQ for z/OS Version 9       *
  *                 Release 1 Modification 0 and                 *
  *                 Release 2 Modification 0.                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: Abend S5C6-00C91200 occurs in CSQICDSQ  *
  *                      when a shared queue is deleted.         *
  *                      The abend is followed by abnormal queue *
  *                      manager termination S6C6 with           *
  *                      REASON=00E50702.                        *
  ****************************************************************
  When a shared queue is deleted, the deleting queue manager
  notifies other queue managers of the deletion so that local
  control blocks can be freed.
  A timing window exists in the processing of these notifications
  where either a subsequent attempt to delete the same queue on
  a different queue manager, or (following application of APAR
  PH39364) a second delete notification, can remove the control
  blocks in question, resulting in the reported abend when the
  first notification attempts to access them.
  

Problem conclusion

• The serialisation of delete notifications processed by CSQMKATM
  is changed to better serialise the deletion of the queue's
  control blocks.
  

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:

  UI80008 UI80289

Modules/Macros

• CSQ5245M CSQ5ERST CSQ5LEPL CSQ5MGX0 CSQ5STRT CSQ5XWK1 CSQ5XWK2
  CSQEWCMQ CSQIDDA1 CSQIRECP CSQMKATM
  

Fix information

• Fixed component name

  IBM MQ Z/OS V9

• Fixed component ID

  5655MQ900

Applicable component levels