Figure 9 and Figure 10 show a queue manager called QM3 that is outside the cluster called DEMO. (QM3 could be a queue manager on a WebSphere MQ product that does not support clusters.) QM3 hosts a queue called Q3, which is defined as follows:
DEFINE QLOCAL(Q3)
Inside the cluster are two queue managers called QM1 and QM2. QM2 hosts a cluster queue called Q2, which is defined as follows:
DEFINE QLOCAL(Q2) CLUSTER(DEMO)
To communicate with a queue manager outside the cluster, one or more queue managers inside the cluster must act as a gateway. The gateway in this example is QM1.
Let us consider how the queue manager that is outside the cluster can put a message to the queue Q2 at QM2, which is inside the cluster.
The queue manager outside the cluster (QM3 in Figure 9) must have a QREMOTE definition for each queue in the cluster that it wants to put messages to. For example:
DEFINE QREMOTE(Q2) RNAME(Q2) RQMNAME(QM2) XMITQ(QM1)
You can see this remote queue on QM3 in Figure 9.
Because QM3 is not part of a cluster, it must communicate using distributed queuing techniques. Therefore, it must also have a sender channel and a transmission queue to QM1. QM1 needs a corresponding receiver channel. The channels and transmission queues are not shown explicitly in Figure 9.
When an application at QM3 issues an MQPUT call to put a message to Q2, the QREMOTE definition causes the message to be routed through the gateway queue manager QM1.
To form a return path for replies, the gateway (QM1) advertises a queue-manager alias for the queue manager outside the cluster. It advertises this alias to the whole cluster by adding the cluster attribute to its queue-manager alias definition. (Remember that a queue-manager alias definition is like a remote queue definition, but with a blank RNAME.) For example:
DEFINE QREMOTE(QM3) RNAME(' ') RQMNAME(QM3) CLUSTER(DEMO)
Again, because QM3 is not part of a cluster, it must communicate using distributed queuing techniques. Therefore, QM1 must also have a sender channel and a transmission queue to QM3. QM3 needs a corresponding receiver channel. The channels and transmission queues are not shown explicitly in Figure 9.
When the application (app2) on QM2 issues an MQPUT call to send a reply to Q3 at QM3, the reply is sent to the gateway, which uses its queue-manager alias to resolve the destination-queue and queue-manager name.
There is another way of putting from a queue manager outside a cluster.
On the gateway queue manager define a queue-manager alias called, for example, ANY.CLUSTER:
DEFINE QREMOTE(ANY.CLUSTER) RNAME(' ') RQMNAME(' ')
This maps any response to the queue manager ANY.CLUSTER to null, which means the QREMOTE definition in the queue manager outside the cluster can use the queue manager name ANY.CLUSTER instead of having to use the exact queue manager name. Therefore, on the queue manager outside the cluster, the definition:
DEFINE QREMOTE(Q2) RNAME(Q2) RQMNAME(ANY.CLUSTER) XMITQ(QM1)
would cause messages to go to QM1 initially, and from there to be routed to any queue manager in the cluster that hosts the cluster queue Q2.
Now let us consider how to put a message from QM2, which is inside the cluster, to the queue Q3 at QM3, which is outside the cluster.
The gateway, in this example QM1, has a QREMOTE definition that advertises the remote queue (Q3) to the cluster:
DEFINE QREMOTE(Q3) RNAME(Q3) RQMNAME(QM3) CLUSTER(DEMO)
It also has a sender channel and a transmission queue to the queue manager that is outside the cluster. QM3 has a corresponding receiver channel. These are not shown in Figure 10.
To put a message, an application on QM2 issues an MQPUT call specifying the target queue name (Q3) and specifying the name of the queue to which replies are to be sent (Q2). The message is sent to QM1, which uses its remote-queue definition to resolve the queue name to Q3 at QM3.
So that QM3 can send replies to the queue managers inside the cluster, it must have a queue-manager alias for each queue manager in the cluster with which it needs to communicate. This queue-manager alias must specify the name of the gateway through which messages are to be routed, that is, the name of the transmission queue to the gateway queue manager. In this example, QM3 needs a queue manager alias definition for QM2:
DEFINE QREMOTE(QM2) RNAME(' ') RQMNAME(QM2) XMITQ(QM1)
QM3 also needs a sender channel and transmission queue to QM1 and QM1 needs a corresponding receiver channel.
The application (app3) on QM3 can then send replies to QM2, by issuing an MQPUT call and specifying the queue name (Q2) and the queue manager name (QM2).
Instead of grouping all your queue managers together in one big cluster, you can have many smaller clusters with one or more queue managers in each 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.) You can use aliases to change the names of queues and queue managers to avoid name conflicts or to comply with local naming conventions.
Figure 11 shows two clusters with a bridge between them. (There could be more than one bridge.) QM1 has defined a cluster queue Q1, as follows:
DEFINE QLOCAL(Q1) CLUSTER(CORNISH)
QM3 has defined a cluster queue Q3, as follows:
DEFINE QLOCAL(Q3) CLUSTER(WINDSOR)
QM2 has created a namelist called CORNISHWINDSOR, containing the names of both clusters:
DEFINE NAMELIST(CORNISHWINDSOR) DESCR('CornishWindsor namelist') NAMES(CORNISH, WINDSOR)
QM2 has also defined a cluster queue Q2, as follows:
DEFINE QLOCAL(Q2) CLUSNL(CORNISHWINDSOR)
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 11, on QM2, you need:
DEFINE QALIAS(MYQ3) TARGQ(Q3) CLUSTER(CORNISH) DEFBIND(NOTFIXED)
This means that an application connected to a queue manager in CORNISH (for example QM1), can put a message to a queue, which it refers to as MYQ3, and this message is routed to Q3 at QM3.
When you open a queue you need to set DEFBIND to either (NOTFIXED) or (QDEF) because if it is left as the default (OPEN) the queue manager will resolve the alias definition to the bridge queue manager that hosts it, and the bridge will not forward the message on.
For each queue manager that you want to make visible, you need a queue-manager alias definition. For example on QM2 you need:
DEFINE QREMOTE(QM1) RNAME(' ') RQMNAME(QM1) CLUSTER(WINDSOR)
This means that 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.
Notices |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
csqzah0732 |