MQ

This is part of an occasional series of small blog posts where I (Morag) will write about some of the quirks in IBM MQ, in the hope of invoking the response, "Well, I didn't know that!" Read other posts in this series.

I wrote a blog post about MO71 the other day that got me thinking about IBM MQ objects which reference other objects, and decided to write about that as this months post.

There are lots of objects in IBM MQ that have within their definition the name of another object. The table below shows a good number of them, although I don't promise that it's complete!

For the most part, the above attributes that refer to other MQ objects, can be defined at any time. For example, you can issue the following two commands in either order and they will not fail. The DEFINE command does not check for the existence of the named objects.

DEFINE CHANNEL(TO.MQG1) CHLTYPE(SDR) TRPTYPE(TCP) CONNAME('gemwin5(1701)') XMITQ(MQG1)
DEFINE QLOCAL(MQG1) USAGE(XMITQ)

Even though the CHANNEL object is created and names the as yet undefined transmission queue, no failure occurs, unless you to try run the channel before the transmission queue is defined.

Another example is a remote queue definition. Here are two more commands that can be issued in either order and they will not fail.

DEFINE QREMOTE(SEND.WORK) RNAME(WORK) RQMNAME(MQG2) XMITQ(MQG2)
DEFINE QLOCAL(MQG2) USAGE(XMITQ)

Even though the QREMOTE is created and names the as yet undefined transmission queue, no failure occurs, unless you try to open the queue in an application, then you will get a reason code of MQRC_UNKNOWN_XMIT_Q.

So, in general, when you DEFINE an object that references another, the referenced object only has to exist when you try to make use of the DEFINEd object.

One DEFINE command that does not obey this rule is the DEFINE command that creates a subscription. A subscription is not really an object in the same sense as channels and queues are. One way that it differs is that it is immediately live, and has status as soon as it is created. I think of subscriptions as something that an application creates, and in that context it makes sense that it is immediately live and "catching" publication messages for the application. The DEFINE command that mimics the MQSUB application call, therefore causes the same behaviour, but that makes it different from other DEFINE commands.

When creating a subscription, it can reference two other objects, a topic and a destination queue. If an object name that it references doesn't exist, the DEFINE SUB command fails. This is, as you can see from the earlier examples, different from other DEFINE commands. So DEFINE SUB is quirky compared to other DEFINE commands.

If you remember that a subscription isn't a static object like a queue or a channel, but is instead a live, running entity like a channel status or a connection handle, then you'll be more likely to remember that creation of a subscription immediately makes it live, and you'll make sure that the queue or topic object that you need to reference in your DEFINE SUB command is defined first.