PH00544: MQ Z/OS: CSQM556E UNABLE TO OPEN TRANSMISSION QUEUE FOR CHANNEL MQRC=2394 (MQRC_Q_INDEX_TYPE_ERROR)

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Reference "Planning how you use multiple cluster transmission
  queues" at
  https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.
  ibm.mq.pla.doc/q118600_.htm
  
  While implementing the use of multiple cluster transmission
  queues, you defined an XMITQ with the CLCHNAME parameter
  specifying the CLUSSDR channel that would use the queue.
  
  This initiated a switch from using the prior transmission queue
  (in this case the default SYSTEM.CLUSTER.TRANSMIT.QUEUE) to
  using the new transmit queue.
  
  The CHIN log had no obvious complaints with
  
    CSQX293I CSQXRCTL CHANNEL <channel-name> IS SWITCHING
    TRANSMISSION QUEUE FROM <old-xmitq> TO <new-xmitq>
  
  However, in the MSTR joblog, the following sequence of messages
  occurred:
  
    CSQM550I CSQMQMR3 SWITCH OF TRANSMISSION QUEUE
    FOR CHANNEL <channel-name> FROM <old-xmitq> TO
    <new-xmitq> STARTED
  
    CSQM553I CSQMCTQM MOVING MESSAGES FOR CHANNEL
    <channel-name> FROM TRANSMISSION QUEUE
    <old-xmitq> TO <new-xmitq>
  
    CSQM556E CSQMCTQM UNABLE TO OPEN TRANSMISSION
    QUEUE <old-xmitq> FOR CHANNEL <channel-name>,
    MQRC=2394 (MQRC_Q_INDEX_TYPE_ERROR)
  
    CSQM555E CSQMCTQM MOVING OF MESSAGES FOR CHANNEL
    <channel-name> FROM TRANSMISSION QUEUE
    <old-xmitq> TO <new-xmitq> FAILED
  
  After the failure to switch, messages continued to go to the
  old-xmitq and built up there. However, the CLUSSDR was running
  with the new-xmitq. Eventually, symptoms such as the following
  occurred when the xmitq filled:
  
    CSQX038E CSQXREPO UNABLE TO PUT MESSAGE TO
    SYSTEM.CLUSTER.TRANSMIT.QUEUE, MQCC=2 MQRC=2053 (MQRC_Q_FULL)
  
    CSQX878I CSQXREPO REPOSITORY COMMAND ERROR,
    COMMAND QUERY_CLQ
    CLUSTER OBJECT <object-name>
    SENDER <sender-qmid>
    REASON=20009511
  
    CSQX053E CSQXFFST ERROR INFORMATION RECORDED IN CSQSNAP DATA
    SET
  
    CSQX448E CSQXREPO REPOSITORY MANAGER STOPPING BECAUSE OF
    ERRORS.  RESTART IN 600 SECONDS
  
  The root of the issue is that the CSQM556E with
  MQRC_Q_INDEX_TYPE_ERROR needed to be resolved. The old-xmitq
  SYSTEM.CLUSTER.TRANSMIT.QUEUE had INDXTYPE(NONE)
  whereas it should have INDXTYPE(CORRLID) as shown in CSQ4INSX.
  The switch was successful when the old-xmitq was correctly
  defined with INDXTYPE(CORRELID).
  
  The Knowledge Center should more clearly document the
  requirement of the INDXTYPE, especially during a switching to
  another xmitq.
  
  Additional Symptom(s) Search Keyword(s):
  

Local fix

• DEFINE or ALTER the cluster tranmission queues to use
  INDXTYPE(CORRELID).
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of IBM MQ for z/OS Version 9       *
  *                 Release 0 Modification 0, Release 1          *
  *                 Modification 0 and Release 2 Modification 0. *
  ****************************************************************
  * PROBLEM DESCRIPTION: When performing a switch of cluster     *
  *                      transmission queues for a channel, if   *
  *                      the queue being switched from has an    *
  *                      INDXTYPE not equal to CORRELID, then    *
  *                      the switch will fail with a CSQM556E    *
  *                      message with MQRC=2394                  *
  *                      (MQRC_Q_INDEX_TYPE_ERROR).              *
  *                                                              *
  *                      This is the correct behaviour, the      *
  *                      problem is that upon restarting the     *
  *                      channel, the channel will start getting *
  *                      from the new queue, whereas puts will   *
  *                      still go to the old queue.              *
  *                                                              *
  *                      This could lead to the old queue        *
  *                      filling which can cause the repository  *
  *                      manager to fail.                        *
  ****************************************************************
  When a request to switch cluster transmission queues is issued,
  the channel will switch to getting from the new transmission
  queue when it is next started. New puts will still go to the old
  transmission queue until all the messages have been moved to the
  new queue. If the original queue has an INDXTYPE other than
  CORRELID, then the moving of the messages will fail.
  
  This leaves the channel in an inconsistent state, where it is
  getting from the new queue but puts are still going to the old
  queue.
  

Problem conclusion

• The switching logic has been changed to fail the switch in a
  consistent manner. This results in the switch failing, but with
  the channel still getting from the old transmission queue.
  

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:

  UI71689 UI71690

Modules/Macros

• CSQMQMR3 CSQXRCRS
  

Fix information

• Fixed component name

  IBM MQ Z/OS V9

• Fixed component ID

  5655MQ900

Applicable component levels

• R000 PSY UI71689

     UP20/10/13 P F010 ¢

• R100 PSY UI71690

     UP20/10/13 P F010 ¢

• R200 PSY UI72047

     UP20/12/22 P F012 ¢

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.