Configuring message paths between clusters
Connect clusters together using a gateway queue manager. Make queues or queue managers visible to all the clusters by defining cluster queue or cluster queue manager aliases on the gateway queue manager.
About this task
Instead of grouping all your queue managers together in one large cluster, you can have many smaller clusters. Each cluster has one or more queue managers in acting as a bridge. The advantage of this is that you can restrict the visibility of queue and queue-manager names across the clusters. See Overlapping clusters. Use aliases to change the names of queues and queue managers to avoid name conflicts or to comply with local naming conventions.
Figure 1 shows two clusters with a bridge between them. There could be more than one bridge.Configure the clusters using the following procedure:
Procedure
What to do next
QM2
is a member of both clusters and is the bridge between them. For each queue that you want to make visible across the bridge, you need a QALIAS
definition on the bridge. For example in Figure 1, on QM2
, you need:
DEFINE QALIAS(MYQ3) TARGET(Q3) CLUSTER(CORNISH) DEFBIND(NOTFIXED)
Using the queue alias, an application connected to a queue manager in CORNISH
, for example QM1
, can put a message to Q3
. It refers to Q3
as MYQ3
. The message is routed to Q3
at QM3
.
When you open a queue, you need to set DEFBIND
to either NOTFIXED
or QDEF
. If DEFBIND
is left as the default, OPEN
, the queue manager resolves the alias definition to the bridge queue manager that hosts it. The bridge does not forward the message.
QM2
you need:
DEFINE QREMOTE(QM1) RNAME(' ') RQMNAME(QM1) CLUSTER(WINDSOR)
An application connected to any queue manager in WINDSOR
, for example QM3
, can put a message to any queue on QM1
, by naming QM1
explicitly on the MQOPEN
call.