PH67669: ABEND5C6 00E70033 ADDITIONAL SYMPTOM : CSQX112E CSQXDISP DISPATCHER PROCESS ERROR, TCB=TCB_ADDR ..... REASON=5C6000-00E70033

APAR status

• Closed as fixed if next.

Error description

• Due to the semaphore table becoming full, an abend dump is
  generated with symptom string DUMP TITLE=xxxx,ABN=
  5C6-00E70033,C=MQ900.943.CHIN OC=CSQXFCTL.CSQXSEM +00BD0.
  Development finds within the CHINIT joblog that the Queued
  Pub/Sub Daemon repeatedly failed due to
  MQRC_CLUSTER_RESOLUTION_ERROR caused by a CLUSTER configuration
  error indicated by messages : +CSQT855E CSQXFCTL Queued Pub/Sub
  Daemon failed, reason=00002189 +CSQX420I CSQXREPO No
  repositories for cluster cluster_name The daemon is then
  restarted each time the CHIN refreshes its view of the QMGR
  parms, which happens when the QMGR puts a CSQM_SET_QMGR_INFO_CMD
  trigger message on the SYSTEM.CHANNEL.INITQ. This looks to be
  happening in response to ALTER QMGR commands being issued. When
  the CHIN supervisor gets one of these trigger messages, it also
  calls CSQXFINI who re-attaches the Queued PubSub Daemon. There
  is a leak of semaphores each time the Queued PubSub Daemon ends
  and is restarted. Eventually this leak fills the table which
  results in the S5C6-00E70033 abend in CSQXSEM.
  

Local fix

• Correcting the cluster configuration problem will prevent the
  Queued PubSub Daemon from repeatedly ending. Alternatively
  PSMODE(DISABLED) can be set.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of IBM MQ for z/OS Version 9       *
  *                 Release 4 Continuous Delivery (CD) Release.  *
  ****************************************************************
  * PROBLEM DESCRIPTION: When configuration errors prevent the   *
  *                      Queued Publish/Subscribe Daemon from    *
  *                      initialising successfully, it may       *
  *                      repeatedly fail and try to restart.     *
  *                      This eventually leads to an ABEND5C6    *
  *                      00E70033 due to a gradual leak of       *
  *                      semaphores resulting in the semaphore   *
  *                      table becoming full.                    *
  ****************************************************************
  Entries in the semaphore table are created using thread-local
  addresses as names, which are not preserved across restarts of
  the daemon. Each restart adds new semaphore entries to the table
  instead of using the previously created ones, eventually causing
  an abend when the table becomes full.
  

Problem conclusion

Temporary fix

Comments

• The use of thread-local addresses for semaphores names has been
  replaced with static semaphore names. This ensures that
  semaphores are reused across daemon restarts, preventing any
  previous leaks.
  

APAR Information

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

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

Fix information

Applicable component levels