A fix is available
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":"LOB45","label":"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