Undoing a change on z/OS
We need to have a process to backout a change if it the results are not as you expect.
What can go wrong?
If the new transmission queue is not what you expect:
- Check the CLCHNAME is as you expect
- Review the job log to check if the switch process has finished. If not, wait and check the new transmission queue of the channel later.
If we are using multiple cluster transmission queues, it is important that you design the transmission queues definitions explicitly and avoid complicated overlapping configuration. In this way, we can make sure that if there are problems, we can go back to the original queues and configuration.
If you encounter problems during the move to using a different transmission queue, we must resolve any problems before we can proceed with the change.
An existing change request must complete before a new change request can be made. For example, you:
- Define a new transmission queue with a maximum depth of one and there are 10 messages waiting to be sent.
- Change the transmission queue to specify the channel name in the CLCHNAME parameter.
- Stop and restart the channel. The attempt to move the messages fails and reports the problems.
- Change the CLCHNAME parameter on the transmission queue to be blank.
- Stop and restart the channel. The channel continues to try and complete the original request, so the channel continues to use the new transmission queue.
- Need to resolve the problems and restart the channel so the moving of messages completes successfully.
Next time the channel is restarted it picks up any changes, so if you had set CLCHNAME to blanks, the channel will not use the specified transmission queue.
In this example, changing the CLCHNAME on the transmission queue to blanks does not necessarily mean that the channel uses the SYSTEM.CLUSTER.TRANSMIT queue, as there might be other transmission queues whose CLCHNAME parameter match the channel name. For example, a generic name, or the queue manager attribute DEFCLXQ might be set to channel, so the channel uses a dynamic queue instead of the SYSTEM.CLUSTER.TRANSMIT queue.
Parent topic: Operate IBM MQ for z/OS