Testing remote WebSphereMQ queue managers

Question

I'd like set up a battery of tests for testing new installations of QMs. Most of them will be in a "remote" setup. I'd like to be able to send a message to the new QM and receive a response. Is there any way to make a "loop" just with normal configuration (ie without using exits) ?

Answer 1

My former employer was a bank and we had many connections to clearing houses and other vendors. On many of these I was able to have the business partner set up loopback queues on their end. These consisted of a QRemote on my QMgr that pointed to a QRemote on the other side, which pointed to a QLocal on the originating QMgr on my side. When a message is PUT to the QRemote it flowed to the other side, landed on the QRemote there, then was directed back to the QLocal.

If the message didn't make it back, we would then start our inbound channel (which was defined as a RQSTR on our side). If this caused the channel to start and the message arrived then we knew the channel initiator on the other side was down but at least we could keep the channel running until it was fixed. But if this didn't work we knew there was some problem on their side other than channel triggering.

And, yes, this was production. We figured that non-transactional instrumentation messages are valid in Production environments. As far as we were concerned, this was the same as a ping or cluster control message. Of course, we had a web screen and other instrumentation to kick them off so usage of the utility was controlled and were recorded.

There are similar methods in which QMgr aliasing is used and this can greatly cut down on the number of loopback queues needed in a large network. Do NOT be tempted to do this! When we use QRemotes that specify a fully-qualified destination, all they can do is send and receive loopback messages on the prescribed queue. But if a QRemote is used without an RQNAME then it can be used to send messages to any queue on the adjacent QMgr.

Let's say you have QMA and QMB :

runmqsc QMA
DEFINE QLOCAL(QMB.LOOPBACK) REPLACE
DEFINE QREMOTE(QMB.LOOPBACK.RMT) +
       XMITQ(QMB) +
       RQMNAME(QMB) +
       RNAME(QMB.QMA.LOOPBACK.RMT) +
       REPLACE
END

runmqsc QMB
DEFINE QREMOTE(QMB.QMA.LOOPBACK.RMT) +
       XMITQ(QMA) +
       RQMNAME(QMA) +
       RNAME(QMB.LOOPBACK) +
       REPLACE

Now you can go to the server hosting QMA and do:

echo Hello World | amqsput QMB.LOOPBACK.RMT QMA

Note that the name of the loopback reflector on QMB has both QMgr names in it. This is because you probably want to set up lopback from both sides and cannot use QMB.LOOPBACK.RMT both as a reflector and to initiate loopbacks. In that case the object inventory looks more like this:

runmqsc QMA
DEFINE QLOCAL(QMB.LOOPBACK) REPLACE
DEFINE QREMOTE(QMB.LOOPBACK.RMT) +
       XMITQ(QMB) +
       RQMNAME(QMB) +
       RNAME(QMB.QMA.LOOPBACK.RMT) +
       REPLACE

DEFINE QREMOTE(QMA.QMB.LOOPBACK.RMT) +
       XMITQ(QMB) +
       RQMNAME(QMB) +
       RNAME(QMA.LOOPBACK) +
       REPLACE
END

runmqsc QMB
DEFINE QREMOTE(QMB.QMA.LOOPBACK.RMT) +
       XMITQ(QMA) +
       RQMNAME(QMA) +
       RNAME(QMB.LOOPBACK) +
       REPLACE

DEFINE QLOCAL(QMA.LOOPBACK) REPLACE
DEFINE QREMOTE(QMA.LOOPBACK.RMT) +
       XMITQ(QMA) +
       RQMNAME(QMA) +
       RNAME(QMA.QMB.LOOPBACK.RMT) +
       REPLACE
END

Note that all of the objects sort out based on the name of the remote QMgr. Some people prefer names like LOOPBACK.QMB.RMT to make all the loopback queues cluster together in a list of objects or a backup.

All of this is a great target for automation since the names of the objects can all be derived from the names of the QMgrs.

Answer 2

I can think of a couple of ways to do this. It rather depends on whether you want to include the MQPUT and MQGET on the remote system target queue.

• Define the target queue as a QREMOTE pointing back to the originating system again with a real QLOCAL as the final destination back on the original system.
• Use something like SupportPac MA01 (Q program) to echo the message back when it lands on a real QLOCAL queue on the remote system. The -e option let's you echo the message back to the ReplyToQ and ReplyToQMgr fields.