PH44869: MSTR ABENDS WITH 5C6-00C5119A DURING PHASE 2 PEER LEVEL RECOVERY

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• There is a timing window whereby a structure is marked as
  failed at the same time as a QMGR is reconnecting to the
  structure which can result in 5C6-00C5119A for the MSTR.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of IBM MQ for z/OS Version 9       *
  *                 Release 1 Modification 0, Release 2          *
  *                 Modification 0 and Release 3 Modification 0. *
  ****************************************************************
  * PROBLEM DESCRIPTION: After CHINIT failures some QMGRs in a   *
  *                      QSG experience 5C6-00C5119A abends      *
  *                      preceded by messages CSQE007I,          *
  *                      CSQE011I, CSQE013I, CSQE012I, CSQE034E  *
  *                      for PLR Peer Level Recovery, however    *
  *                      all of the messages have blank          *
  *                      structure and connection names. The     *
  *                      5C6-00C5119A abend is followed by a     *
  *                      5C6-00C510AD and QMGR termination with  *
  *                      reason 00C510AB.                        *
  ****************************************************************
  After some CHINIT failures the structure is marked as failed and
  each of the QMGRs disconnect from it. One of the other QMGRs in
  the QSG then initiates structure recovery and when it is almost
  complete CSQECONN runs to reconnect to the structure.
  CSQECONN does the required IXLCONN, and then calls CSQEDSC1 with
  CSQE_DSC1_CONNECT_ALL. This detects that the structure has once
  again been marked as failed so calls CSQESTFA to simulate
  receiving an EeplStrFailure structure event. CSQESTFA gets a
  fresh STRB, performing only minimal initialisation on it.
  When control returns from CSQEDSC1, CSQECONN notices that the
  connection needs recovery, so calls CSQERAS1 to kick off PLR for
  its own connection to the structure. CSQERAS1 attempts to use
  the fresh STRB, even though key fields such as the structure
  name have not been initialised and still contain nulls. This
  results in CSQE messages without structure and connection names
  and ultimately a 5C6-00C510AD abend during phase 2 PLR as the
  connection token to the failed application structure is null.
  

Problem conclusion

• CSQECONN has been updated to check if the STRB contains a
  structure name before calling CSQERAS1. If not Peer Level
  Recovery fails with reason code CsqeRsnCodeNoConnectivity
  '00C5000A'X. A further recovery attempt can be made immediately.
  

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:

  UI91930 UI91931 UI91932

Modules/Macros

• CSQECONN
  

Fix information

• Fixed component name

  IBM MQ Z/OS V9

• Fixed component ID

  5655MQ900

Applicable component levels

• R100 PSY UI91932

     UP23/06/15 P F306

• R200 PSY UI91931

     UP23/06/15 P F306

• R300 PSY UI91930

     UP23/06/15 P F306

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.