Procedure

1. Determine which full repository the queue managers will refer to first

Every member of a cluster must refer to one or other of the full repositories to gather information about the cluster and so build up its own partial repository. It is of no particular significance which full repository you choose. In this example we choose NEWYORK. Once the queue-sharing group has joined the cluster, it will communicate with both of the full repositories.

2. Define the CLUSRCVR channels

Every queue manager in a cluster needs to define a cluster-receiver channel on which it can receive messages. On POLO1, POLO2, and POLO3, define:

DEFINE CHANNEL(TO.POLOn) CHLTYPE(CLUSRCVR) TRPTYPE(TCP)
CONNAME(POLOn.CHSTORE.COM) CLUSTER(INVENTORY)
DESCR('Cluster-receiver channel for sharing queue manager')

This advertises each queue manager's availability to receive messages from other queue managers in the cluster INVENTORY.

3. Define a CLUSSDR channel for the queue-sharing group

Every member of a cluster needs to define one cluster-sender channel on which it can send messages to its first full repository. In this case we have chosen NEWYORK. One of the queue managers in the queue-sharing group needs the following group definition in order to ensure every queue manager has a cluster-sender channel definition:

DEFINE CHANNEL(TO.NEWYORK) CHLTYPE(CLUSSDR) TRPTYPE(TCP)
CONNAME(NEWYORK.CHSTORE.COM) CLUSTER(INVENTORY) QSGDISP(GROUP)
DESCR('Cluster-sender channel to repository at NEWYORK')

4. Define the shared queue

Define the queue INVENTQ on POLO1 as follows:

DEFINE QLOCAL(INVENTQ) CLUSTER(INVENTORY) QSGDISP(SHARED) CFSTRUCT(STRUCTURE)

Now that you have completed all the definitions, if you have not already done so, start the channel initiator and a listener program on the new queue manager. The listener program listens for incoming network requests and starts the cluster-receiver channel when it is needed. See Establishing communication in a cluster for more information.

The cluster set up by this task looks like this:

Figure 22. Cluster and queue-sharing group
Cluster and queue-sharing group is described in the surrounding text.

Now messages put on the INVENTQ queue by LONDON are routed alternately around the four queue managers advertised as hosting the queue.

One of the benefits of having members of a queue-sharing group hosting a cluster queue is that, if the queue manager that made the queue definition (in this case POLO1) becomes unavailable after receiving a message on the shared queue, and is unable to reply, any other member of the queue-sharing group can reply instead.

Note:
Also refer to the chapter on Intra-group queuing in the WebSphere MQ Intercommunication for details of configuring clustering with intra-group queuing.