IBM Support

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

A fix is available

Subscribe

You can track all active APARs for this component.

 

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 number

    PH00544

  • Reported component name

    IBM MQ Z/OS V9

  • Reported component ID

    5655MQ900

  • Reported release

    000

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    YesHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2018-07-16

  • Closed date

    2020-09-22

  • Last modified date

    2021-01-04

  • 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.

[{"Line of Business":{"code":"LOB36","label":"IBM Automation"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"9.0"}]

Document Information

Modified date:
05 January 2021