Potential issues when switching transmission queues
A list of some issues that might be encountered when switching transmission queue, their causes, and most likely solutions.
![[z/OS]](ngzos.gif)
Insufficient access to transmission queues on z/OS
A cluster-sender channel on z/OS® might report it is not authorized to open its transmission queue.
The channel is switching, or has switched, transmission queue and the channel initiator has not been granted authority to access the new queue.
Grant the channel initiator the same access to the channel's transmission queue that is documented for the transmission queue SYSTEM.CLUSTER.TRANSMIT.QUEUE. When using DEFCLXQ a generic profile for SYSTEM.CLUSTER.TRANSMIT.** avoids this problem occurring whenever a new queue manager joins the cluster.
Moving of messages fails
Messages stop being sent by a channel and they remain queued on the channel's old transmission queue.
The queue manager has stopped moving messages from the old transmission queue to the new transmission queue because an unrecoverable error occurred. For example, the new transmission queue might have become full or its backing storage exhausted.
Review the error messages written to the queue manager's error log (job log on z/OS) to determine the problem and resolve its root cause. Once resolved, restart the channel to resume the switching process, or stop the channel then use runswchl instead (CSQUTIL on z/OS).
A switch does not complete
The queue manager repeatedly issues messages that indicate it is moving messages. The switch never completes because there are always messages remaining on the old transmission queue.
Messages for the channel are being put to the old transmission queue faster than the queue manager can move them to the new transmission queue. This is likely to be a transient issue during peak workload because if were commonplace then it is unlikely the channel would be able to transmit the messages over the network fast enough.
There are uncommitted messages for the channel on the old transmission queue.
The new transmission queue or the storage medium hosting it has filled.
- Start the channel to begin moving messages
- Free space on a full remote (target) queue if this is causing the channel to back up
- Increase the MAXDEPTH attribute on the transmission queue
Accidental deletion of a transmission queue
Channels unexpectedly switch due to the removal of a matching CLCHNAME value.
A put to a cluster queue fails with MQRC_UNKNOWN_XMIT_Q.
A channel abnormally ends because its transmission queue does not exist.
The queue manager is unable to move messages to complete a switch operation because it cannot open either the old or the new transmission queue.
The transmission queue currently used by a channel, or its previous transmission queue if a switch has not completed, has been deleted.
Redefine the transmission queue. If it is the old transmission queue that has been deleted then an administrator may alternatively complete the switch operation using runswchl with the -n parameter (or CSQUTIL with MOVEMSGS(NO) on z/OS).
Use the -n parameter with caution because, if it is used inappropriately, messages for the channel can complete and finish processing but not be updated on the old transmission queue. In this scenario it is safe because as the queue does not exist there cannot be any messages to complete and finish processing.