IBM MQ basics: remote queues and channels

In the first install­ment of the IBM MQ Basics, avail­able here, I showed you basic queue cre­ation and usage.

If IBM MQ would only allow local queues to be cre­at­ed and used, it would be less use­ful. One of the strengths of IBM MQ is the abil­i­ty to link two or more queue man­agers and send mes­sages to anoth­er queue manager.

In this arti­cle, I’m going to show you how to link two queue man­agers using a remote queues and channels.

First of all, you need two dif­fer­ent queue man­agers. It does­n’t mat­ter if they are in the same machine. I’m using two machines (actu­al­ly, two vir­tu­al machines in my work machine, but the end result is absolute­ly the same).

I’m using the same queue man­ag­er that I con­fig­ured in the last arti­cle of this series and anoth­er one, named QM2, with the same con­fig­u­ra­tion, that is, a lis­ten­er named LISTENER.TCP, with trans­port type (TRPTYPE) TCP, lis­te­nen­ing on port 1414 and a chan­nel for admin­is­tra­tion pur­pos­es of type serv­er con­nec­tion (SVRCONN) name CLNT.ADM.

Remote queues

A remote queue is a queue like any oth­er, with a few notable exceptions:

• it is impos­si­ble to read from; it can only be writ­ten to;
• it refers to anoth­er queue (remote, local, or alias) in anoth­er queue manager;
• it does not occu­py any hard disk space, except for the space need­ed to store its definition;
• you can (and should) spec­i­fy a trans­mis­sion queue (more on this type of queue later);

Channels and channel types

Com­mu­ni­ca­tion between queue man­agers and between clients and queue man­agers is always done using channels.

Chan­nels’ names can be at most 21 char­ac­ters long.

We’ve already talked about one type of chan­nel (the SVRCONN type). The serv­er-con­nec­tion chan­nel is used for com­mu­ni­cat­ing between MQ client appli­ca­tions and a queue manager.

The oth­er two types of chan­nels I am going to talk about now are the sender chan­nel (SDR) and receiv­er chan­nel (RCVR) types.

As their name implies, the receiv­er chan­nel is used as the receiv­ing end of a sender chan­nel. So, they always come in pairs.

The sender and receiv­er chan­nels must have the same name. That’s how a send­ing queue man­ag­er iden­ti­fies the receiv­ing end.

Transmission queues

Final­ly, one must define a trans­mis­sion queue before cre­at­ing a sender channel.

This is a spe­cial type of local queue (you can write to and read from it, although it is not advis­able) that serves as a tem­po­rary mes­sage store for mes­sages being sent to a remote queue man­ag­er. If, for exam­ple, the remote queue man­ag­er is down for some rea­son or the net­work con­nec­tion between the two queue man­agers is not avail­able, the send­ing queue man­ag­er stores the mes­sages des­tined to the remote one in this type of queue.

For each sender chan­nel you need cre­ate a trans­mis­sion queue.

Putting it all together

Configuring QM1

Ok. Let ‘s start.

In the fol­low­ing exam­ple, I’m going to cre­ate a remote queue in the QM1 queue man­ag­er that refers to a local queue in the QM2 queue manager.

Begin­ning with the QM1 queue manager.

First, cre­ate a trans­mis­sion queue:

DEFINE QLOCAL(‘TO.QM2.X’) USAGE(XMITQ) TRIGGER TRIGDATA(TO.QM2) TRIGTYPE(FIRST)

This com­mand defines some­thing not dis­cussed above: trig­ger­ing. For now, let me just say that the last three options enables auto start­ing the chan­nel named TO.QM2 when a mes­sage is placed in the TO.QM2.XmitQ trans­mis­sion queue.

Next, we need to cre­ate a sender channel:

DEFINE CHANNEL(TO.QM2) CHLTYPE(SDR) CONNAME(‘mq2(1414)’) XMITQ(‘TO.QM2.X’)

This com­mand defines a sender chan­nel named TO.QM2 to host mq2, TCP port 1414 that uses the TO.QM2.XmitQ trans­mis­sion queue.

Final­ly, to wrap the con­fig­u­ra­tions in the QM1 queue man­ag­er, define the Q2.W remote queue:

DEFINE QREMOTE(Q2.W) RQMNAME(QM2) RNAME(Q2.R) XMITQ(‘TO.QM2.X’)

This remote queue def­i­n­i­tion has a con­fig­u­ra­tion option which is not wide­ly used: the option XMITQ. This option allows you to choose the sender chan­nel which will be used by this remote queue by spec­i­fy­ing its trans­mis­sion queue. If you do not spec­i­fy the trans­mis­sion queue used by a remote one, the queue man­ag­er will choose an appro­pri­ate chan­nel to send your mes­sages through.

Configuring QM2

The con­fig­u­ra­tion for the QM2 queue man­ag­er is very simple.

First, define a local queue with the name of the RNAME option of the remote queue you cre­at­ed in QM1 (Q2.R).

DEFINE QLOCAL(Q2.R)

Final­ly, define a receiv­er chan­nel with the same name of the sender chan­nel defined in the QM1 queue manager.

DEFINE CHANNEL(TO.QM2) CHLTYPE(RCVR)

Testing

In the mq1 machine run the fol­low­ing command

~$ /opt/mqm/samp/bin/amqsput Q2.W QM1
Sam­ple AMQSPUT0 start
tar­get queue is Q2.W
Hel­lo, World!
end
End of messages
Sam­ple AMQSPUT0 end

And, in the mq2 machine:

~$ /opt/mqm/samp/bin/amqsget Q2.R QM2
Sam­ple AMQSGET0 start
mes­sage <Hel­lo, World!>
mes­sage <end>
mes­sage <End of messages>
^C

That’s a wrap.

Stay tuned. In the next post, I’ll be talk­ing about the publish/subscribe feature.