- CURDEPTH is high in DISPLAY QUEUE or DISPLAY QSTATUS output for SYSTEM.CLUSTER.TRANSMIT.QUEUE
- MSGAGE and QTIME increase in DISPLAY CHSTATUS output for SYSTEM.CLUSTER.TRANSMIT.QUEUE
The SYSTEM.CLUSTER.TRANSMIT.QUEUE contains thousands of messages that required examination for reallocation. The problem is aggravated by having small buffer pools, which means I/O to the page set is necessary.
Resolving The Problem
- Start the listener on the remote end
- Use ADOPTMCA / AdoptNewMCA on the remote end so that the clusrcvr channel can be automatically restarted after a communications failure. If this feature has not been implemented, stop the receiver channel with MODE(FORCE), then start it again to re-enable it.
- Use TCPKEEP / KeepAlive / RCVTIME to recover from communications failures
- Resolve network problems
- If this can not be done immediately, you can stop the channel to prevent it from retrying. See additional information below about stopping the channel. Another option is to decrease LONGRTY or increase LONGTMR, so that retries will not occur as frequently.
- If you do not need your messages bound to a specific instance of the cluster queue, then use the MQOO_BIND_NOT_FIXED option. This will allow the messages to be allocated to another channel. The reallocation process is less efficient if each iteration must examine thousands of messages put using the MQOO_BIND_ON_OPEN option.
- Make sure your Buffer Pool allocations are large enough, as described in Defining your buffer pools .
- Be sure the target queue on the remote end is not full. If it is, the CLUSRCVR channel trying to put the message will receive reason 2053 MQRC_Q_FULL. If there is not a Dead Letter Queue (DLQ) defined on the remote queue manager or if the DLQ is full, the messages will build up on the sending SYSTEM.CLUSTER.TRANSMIT.QUEUE and the CLUSSDR channel will enter the reallocation and retry processing.
With WebSphere MQ for z/OS MQ V7 and above:
Channel channel-name message reallocation is in
progress, msg-progress messages of msg-total processed
Channel channel-name completed message
reallocation, msg-processed messages processed
2) STOP CHANNEL MODE(FORCE/TERMINATE) is allowed to interrupt reallocation processing.
3) Message CSQX192E is issued when a STOP CHANNEL without FORCE or TERMINATE is issued and the channel is in reallocation processing.
Recycling the CHIN will also interrupt reallocate processing, but reallocation will occur after startup if the channel again fails to start.
Effects which may be seen if reallocate processing is interrupted:
- Messages are delivered in a different order in which they were put.
- Messages remain on the SYSTEM.CLUSTER.TRANSMIT.QUEUE until the channel is manually restarted despite there being alternative destinations.
WMQ WebSphere MQ
17 July 2020