You do not indicate the version of MQ or do not report the proximity or dependence on the conservation of MQMD.MsgID . This is important when developing a solution to this problem. I will try to describe enough options so that at least one is viable with whatever version you are on.
Pub / Sub
The easiest thing to do is send messages to an alias on a topic. Any message that arrives is published immediately on this topic. Then just create an administrative subscription to direct messages in the queue, in which applications that require messages are listened to. This is a complete reconfiguration and does not require external components, processes or code. It is available from version 7 of MQ and higher, that is, any of the currently supported versions of MQ.
The downside is that IBM MQ will change the value of MQMD.MsgID from the moment you receive a message on this topic until it is posted to the application input queue. This impairs the ability of the application to use the incoming message MQMD.MsgID as a correlation identifier in response. If the requesting application preloads the correlation identifier or does not rely on the correlation identifier, this is not a problem.
Distortions
But for applications where this is a problem, it gets a little trickier. You can use an alias in the queue and have incoming messages on the alias. When you need to switch from one queue to another, you change the alias. There are a couple of questions with this. First, it is never possible to transfer a message flow to more than one of the applications. In a parallel processing test, it is often desirable to do just that, and then compare summary or detailed reports.
The second problem is more operational. It is not possible to change the alias while it is open. If messages arrive via
RCVR ,
RQSTR or `CLUSRCVR, there is no problem. Stop the channel, switch the alias, and restart the channel. In the MQSC script series of commands, this can be done faster than you can type. However, if the applications hosting the messages are connected in binding mode or through the client directly to the alias, all of them must be stopped in order to change the alias.
However, aliasing works on all versions of MQ out of the box.
Physical copy
One solution that has been around for quite some time is to use the Q program ( SupportPac MA01 ) to send messages. In this case, the queue on which messages are sent is a local queue. The Q program is started or installed for continuous listening in the queue. When the message arrives, Q will then copy it to one or both of the destination queues.
Switching behavior, if Q triggered, includes a preliminary definition of 2 or 3 processes in which each defines a different behavior - move new messages to QUEUEA , to QUEUEB or both. Changing the attribute of a PROCESS queue to indicate another process leads to an instant change in behavior.
Alternatively, if Q is configured to listen on the queue forever, then changing the behavior involves using three different scripts to execute it, when one copy of messages is copied to QUEUEA , the other to QUEUEB , and the other to both queues. The behavior change is associated with killing script and the beginning of another.
The Q program works with all versions of MQ, regardless of whether it is running or a script is written.
The disadvantages of this approach include the obvious - more moving parts. You must call the queue or force the transaction program to act as a daemon. It’s not difficult, but if you are betting on a business, perhaps some monitoring to make sure that the input queue does not start.
Recommendation
Of all these methods, I really like the Pub / Sub version. It is extremely reliable, has the least moving parts and, if something breaks it under the support of IBM. When you need to change something, you can do it with minimal impact on running applications. If at all possible, use this.