PH65572: CSQEDB2R IS PASSING A NULL CONTOKEN ON THE IXL CALL

APAR status

• Closed as program error.

Error description

• QMGR trace shows that structure XXXXXXXXX is being opened on
  QMGR YYYY in response to receiving a ektm_Tap_flag kiss and
  tell (K&T) message from another QMGR in the QSG closing a
  shared queue and finding that it is the last closer in the QSG.
  QMGR YYYY responds to this K&T by opening the shared queue from
  CSQMTAPB. Since YYYY hasn't connected to the underlying CF
  structure, it connects as part of the open, all of which
  happens on the corresponding structure task. Following a
  successful connect, a Csqe_Sync_With_DB2 request is queued to
  the same structure task to be processed immediately following
  the open.
  
  Since structure XXXXXXXXX is configured with SMDS offloading,
  the structure task needs to connect to the SMDS as part of the
  connection. This takes ~8 seconds due to the problem which we
  recently raised APAR PH65545 for. During these 8 seconds, the
  queue being opened is deleted on another QMGR in the QSG. Once
  the connection to the SMDS is completed, the open logic tries
  to read the queue definition from the CF and from Db2, but this
  fails as the queue has been deleted. As the connect was done as
  part of the open, and the open of the queue failed, CSQEOPEN
  decides that it needs to also disconnect from the structure,
  which completes successfully. The open processing returns from
  the structure task with error reason
  CsqeRsnCodeSQueueRecNotFound indicating that the CF structure
  couldn't be opened.
  
  The structure task then carries on processing requests queued
  to it. The next request to process is the Csqe_Sync_With_DB2
  request, which was scheduled as part of the failing open. This
  calls CSQEDB2R to resync queue definitions between Db2 and the
  data in the CF structure. Unfortunately this routine doesn't
  check if we're still connected to the CF structure, and ends up
  passing a NULL CONTOKEN on the IXL call to read the MQSH from
  the CF structure which results in the IXL call failing with
  ixlRsnCodeBadContoken. It also traces a null structure name
  which can be seen in the CSQEDB2R entry trace.
  
  The symptom may include an abend 0C4-10 in IXLR1LST reported in
  LOGREC, but it is retried without an external abend, and the
  returned IxlRsnCodeBadConToken is handled by our code correctly.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of IBM MQ for z/OS Version 9       *
  *                 Release 4 Continuous Delivery (CD) Release   *
  ****************************************************************
  * PROBLEM DESCRIPTION: Users may notice system abends (S0C4)   *
  *                      recorded in LOGREC, originating from    *
  *                      XCF. These errors are retried           *
  *                      automatically without generating a      *
  *                      system dump, making them harder to      *
  *                      detect and diagnose.                    *
  ****************************************************************
  The issue occurs when a queue manager attempts to synchronise
  queue definitions after a failed attempt to open a shared
  queue. If the queue has been deleted during this process, the
  synchronisation step proceeds without verifying the connection
  status, resulting in an invalid request that causes the system
  abend.
  

Problem conclusion

• The fix ensures that the system checks whether a valid
  connection exists before attempting to synchronise queue
  definitions. If no connection is found, the process now ends
  safely with a clear error message, preventing the system abend.
  

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:

Fix information

• Fixed component name

  IBM MQ Z/OS V9

• Fixed component ID

  5655MQ900

Applicable component levels