PH26671: All channel processing hangs some weeks after user deletes cluster transmission queue

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Due to a missing cluster transmission queue, the MQ cluster
  repository process abends.
  On zOS the CHIN CSQSNAP output will contain
  *X...XFFSrrmRemoveNonReallocMsgs.*
  *........MOVR......n...6}X...XINS*
  
  Also, may see
  *        X...XFFSrrmRepository...*
  D4D6E5D9 00000005 20009509 2FD411A8
  The 9509 indicates an MQOPEN failure in the CHIN.
  
  The MSTR joblog will contain
  MQRC_UNKNOWN_OBJECT_NAME
  for SYSTEM.CLUSTER.TRANSMIT.QUEUE or
  other transmission queues that has
  CLCHNAME attribute in the definition.
  +CSQX036E qmgr CSQXREPO Unable to open  910.
  910   QUEUE(SYSTEM.CLUSTER.TRANSMIT.QUEUE),.
  910   MQCC=2 MQRC=2085 (MQRC_UNKNOWN_OBJECT_NAME).
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All Users of IBM MQ for z/OS Version 9       *
  *                 Release 0 Modification 0                     *
  ****************************************************************
  * PROBLEM DESCRIPTION: An FFST occurs during cluster           *
  *                      maintenance (reported by CSQX053E),     *
  *                      when an expired cluster channel record  *
  *                      is removed from the cluster cache for   *
  *                      a Partial Repository QMGR, and the      *
  *                      corresponding xmitq (transmission       *
  *                      queue) for that channel has already     *
  *                      been deleted.                           *
  *                                                              *
  *                      CSQSNAP DD shows the "20009509" FFST    *
  *                      occurs in rrmRemoveNonReallocMsgs.      *
  *                                                              *
  *                      This can result in the processing for   *
  *                      other channels hanging.                 *
  ****************************************************************
  The user deleted a locally defined queue that was previously
  associated as the transmission queue for a local cluster sender
  channel.
  
  When that channel was not used for a long time (over 90 days)
  then, via internal automated processing in the queue manager's
  cluster repository manager, the local auto-defined channel
  definitions for it were expired from the local cluster cache.
  
  At this time the queue manager was calling MQOPEN on the
  cluster transmission queue that was configured for that channel.
  
  If the user had deleted the queue, then this failed, and in the
   error-handling logic that follows, the queue manager
   deadlocked waiting for a mutex that would not be released.
  

Problem conclusion

• A condition has been added to allow toleration of a
  missing xmit queue as part of cluster maintenance, preventing
  this from causing an abend in this one situation.
  

Temporary fix

Comments

APAR Information

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

  PI88958

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

  UI71583

Modules/Macros

• CMQXRMNT CSQXRRMF
  

Fix information

• Fixed component name

  IBM MQ Z/OS V9

• Fixed component ID

  5655MQ900

Applicable component levels

• R000 PSY UI71583

     UP20/10/13 P F010 ¢

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.