PH60014: ABEND0C4 AGAINST CHINIT CSQXCCMX

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• During shutdown of the CHIN the user receives an ABEND0C4 (
  CSQXCCMX+OFFSET) as MQ attempts to free storage which is
  already freed. Development finds that there is a defect in the
  serialisation between the receive and async threads of a
  SHARECNV > 0 multiplexed SVRCONN channel. The CHIN is told to
  stop and the async consumer notifier task ends. This results in
  a flag being set in the xGWA which results in future requests
  to add an async signaller from async threads being rejected
  with an internal return code. When this happens, the async
  thread notifies the receive thread which results in message
  CSQX772E being issued with MQRC 2202
  (MQRC_CONNECTION_QUIESCING). If the receive thread receives
  this notification while trying to resume an async thread
  consumer, then the receive thread can incorrectly determine
  that the async thread is ending.
  This can later result in the receive thread freeing storage
  required by the async thread while it is still active. The
  exact sequence of events which follow this are again predicated
  on certain timing conditions between the receive and async
  threads. Development expects this problem can only occur during
  CHIN/QMGR shutdown, and will always be accompanied by message
  CSQX772E being issued with MQRC=2202
  (MQRC_CONNECTION_QUIESCING). It is suspected that this problem
  could also result in slightly different 0C4 abends depending on
  how the freed storage is reused.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of IBM MQ for z/OS Version 9       *
  *                 Release 2 Modification 0 and                 *
  *                 Release 3 Modification 0.                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: Abend 0C4 occurs in CSQXCCMX during     *
  *                      channel initiator shutdown when client  *
  *                      connections are active.                 *
  ****************************************************************
  The asynchronous consumer task for a client connection detected
  the channel initiator was shutting down, and attempted to return
  an error to the receiver task for the same connection as part of
  the response to a 'resume' request.
  This led to the receiver task incorrectly marking the consumer
  as inactive.
  Later on in channel termination processing, the receive thread
  did not perform the expected serialisation with the asynchronous
  consumer task due to this incorrect state and proceeded to free
  control blocks associated with the channel.
  When the asynchronous task regained control of the dispatcher,
  a timing condition meant that it did not detect the channel
  termination correctly, and attempted to reference freed storage
  resulting in the reported abend.
  

Problem conclusion

• The communication between the receiver task and asynchronous
  task has been changed so that the consumer state is not
  incorrectly set to inactive, with the result that the
  serialisation between these tasks at channel termination will
  now work as intended.
  

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:

  UI97307 UI97308

Modules/Macros

• CSQXRSTM
  

Fix information

• Fixed component name

  IBM MQ Z/OS V9

• Fixed component ID

  5655MQ900

Applicable component levels

• R200 PSY UI97308

     UP24/06/27 P F406

• R300 PSY UI97307

     UP24/06/27 P F406

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.