PH36316: IBM MQ Z/OS V9.2: 0C4 ABENDS IN CSQXRFEA AND CSQXJST AFTER QMGR RESTART

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• 0C4 abends occurred in CSQXRFEA and CSQXJST after QMGR restart.
  The 0C4 abends look like as below:
  ABN= 0C4-00000011, C=MQ900.920.CHIN,M=CSQXARR1,LOC=CSQXJST
  .CSQXRFEA
  ABN= 0C4-00000010, C=MQ900.920.CHIN,M=CSQXARR1,LOC=CSQXJST
  .CSQXRFEA
  ABN= 0C4-00000004, C=MQ900.920.CHIN,M=CSQXJST ,LOC=CSQXJST
  .CSQXJST
  
  MQ dev recreated the problem in the lab. The QMGR starts up,
  starts the CHIN and then immediately encounters the
  0E0-00000028 abend problem which brings down the QMGR.
  Meanwhile, the CHIN is partway through startup and has obtained
  the QMGR SCOM address, it then goes into a wait until the QMGR
  has finished starting up. In this case, the QMGR has gone away
  so the CHIN will end up waiting until the QMGR is restarted.
  
  It looks like automation then restarted the QMGR, who starts a
  new CHIN instance. As part of startup, the QMGR sees the old
  waiting CHIN instance, and wakes it up. The old CHIN goes on
  and tries in CSQXRFEA and CSQXJST to reference data in the QMGR
  SCOM address that it previously obtained. Since the QMGR
  associated with that SCOM has gone away, then depending on how
  the storage is reused, this may result in 0C4 abends. Note that
  these 0C4 abends are for the old CHIN instance, and not the new
  one starting up with the restarted QMGR. Depending on the
  timing of the new CHIN instance starting up, it may also fail
  to connect to the QMGR. This can be seen in the joblog by a
  CSQX007E message with reason code MQRC_DUPLICATE_RECOV_COORD
  and the adapter tasks failing to start.
  

Local fix

• Changing the automation to wait a little bit after the QMGR has
  started to start the CHIN should prevent this problem.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of IBM MQ for z/OS Version 9       *
  *                 Release 2 Modification 0.                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: Abend 0C4 occurs in CSQXRFEA and/or     *
  *                      CSQXJST when starting the queue manager *
  *                      if the queue manager had previously     *
  *                      terminated abnormally while the chinit  *
  *                      was still starting.                     *
  ****************************************************************
  During channel initiator startup the chinit attempted to connect
  to the queue manager, however the queue manager terminated
  before it could do so.
  CSQXACON detected that the queue manager was unavailable and
  waited until posted that it was available again. However as
  certain queue manager control blocks had been freed by the
  queue manager termination and allocated at a different address
  when restarted, attempts to use them after the chinit had been
  resumed led to the reported abends.
  

Problem conclusion

• CSQXACON will perform additional validation of the queue manager
  state when connecting during chinit startup.
  

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:

  UI76656

Modules/Macros

• CSQXACON CSQXGWAI
  

Fix information

• Fixed component name

  IBM MQ Z/OS V9

• Fixed component ID

  5655MQ900

Applicable component levels

• R200 PSY UI76656

     UP21/09/29 P F109

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.