How does WMQ exchange DLQ information between remote and local queue managers?

Question

When a local queue manager receives the following message in it's AMQ error log:

09/13/12 08:00:19 - Process(3017.20) User(mqm) Program(amqrmppa_nd) AMQ9544: Messages not put to destination queue.

EXPLANATION: During the processing of channel 'TO_QM_QD2T1_C1' one or more messages could not be put to the destination queue and attempts were made to put them to a dead-letter queue. The location of the queue is 2, where 1 is the local dead-letter queue and 2 is the remote dead-letter queue.

... what is the mechanism by which MQ exchanges such information? Is there a built in facility within the channel program API itself, or is the info exchanges as discrete messages placed on the SYSTEM.CLUSTER.COMMAND.QUEUE (in the case of a cluster)? Given that this could occur in a remote queue definition situation, with only simple sender/receiver channel pairs, and no corresponding COMMAND QUEUE necessarily, I could imagine that it would be handled via the channel process communications... just wondering...

Answer 1

The channel agents have a bi-directional communication between them, even though messages flow in only one direction. When a message fails to find the destination at the remote end there are several possibilities for what happens next. The channel will only continue to run if the message can be successfully put somewhere and the first place to try is the remote DLQ. If that fails, the local MCA must either relocate the message or stop the channel. Therefore, the two message channel agents work out between them what happens and what the status of the channel should be.

The peculiar wording of the error message reflects that the different dispositions of the message derive from within the same code path and exception handling and the optimization of WMQ. The MCA knows the message was put to a DLQ at that point and rather than having two different error messages or logic to work out the wording on which DLQ was used, it just drops a number into a template. Thus a single error message and streamlined logic are used for both possibilities.