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. Bridging across clusters
Bridging across clusters is described in the preceding text.
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

  1. Define a cluster queue, Q1 on QM1.
    
    DEFINE QLOCAL(Q1) CLUSTER(CORNISH)
    
  2. Define a cluster queue, Q3 on QM3.
    
    DEFINE QLOCAL(Q3) CLUSTER(WINDSOR)
    
  3. Create a namelist called CORNISHWINDSOR on QM2, containing the names of both clusters.
    
    DEFINE NAMELIST(CORNISHWINDSOR) DESCR('CornishWindsor namelist')
    NAMES(CORNISH, WINDSOR)
    
  4. Define a cluster queue, Q2 on QM2
    
    DEFINE QLOCAL(Q2) CLUSNL(CORNISHWINDSOR)
    

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.

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)

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.