Procedure

1. Determine which full repository LOSANGELES should refer to first

Every queue manager in 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 repository you choose. In this example we choose NEWYORK. Once the new queue manager has joined the cluster it will communicate with both of the repositories.

2. Define the CLUSRCVR channel

Every queue manager in a cluster needs to define a cluster-receiver channel on which it can receive message. This is also where we indicate that LOSANGELES can process twice as many messages as NEWYORK. On LOSANGELES define:

DEFINE CHANNEL(TO.LOSANGELES) CHLTYPE(CLUSRCVR) TRPTYPE(TCP) CONNAME(LOSANGELES.CHSTORE.COM) CLUSTER(INVENTORY) DESCR('Cluster-receiver channel for LOSANGELES') CLWLWGHT(2)

3. Define a CLUSSDR channel on queue manager LOSANGELES

Every queue manager in 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, so LOSANGELES needs the following definition:

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

4. Alter the CLUSRCVR channel on queue manager NEWYORK

To ensure that the Los Angeles queue manager gets twice as many of the inventory messages as New York, we need to alter the definition of the cluster-receiver channel:

ALTER CHANNEL(TO.NEWYORK) CHLTYPE(CLUSRCVR) CLWLWGHT(1)

5. Review the inventory application for message affinities

Before proceeding, ensure that the inventory application does not have any dependencies on the sequence of processing of messages. See Reviewing applications for message affinities for more information.

6. Install the inventory application on the system in Los Angeles

See the WebSphere MQ Application Programming Guide for information about how to do this.

7. Define the cluster queue INVENTQ

The INVENTQ queue, which is already hosted by the NEWYORK queue manager, is also to be hosted by TORONTO. Define it on the TORONTO queue manager as follows:

DEFINE QLOCAL(INVENTQ) CLUSTER(INVENTORY)

Now that you have completed all the definitions, if you have not already done so you should start the channel initiator and, on all platforms, start a listener program on queue manager TORONTO. 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 29. The INVENTORY cluster with four queue managers
The diagram shows the INVENTORY cluster, with four queue managers LOS ANGELES, LONDON, NEWYORK, PARIS. LOSANGELES and NEWYORK are hosting queue manager INVENTQ and the inventory application.

The INVENTQ and inventory application are now hosted on two queue managers in the cluster. This increases their availability, speeds up throughput of messages, and allows the workload to be distributed between the two queue managers. Messages put to INVENTQ by either LOSANGELES or NEWYORK are handled by the instance on the local queue manager whenever possible. Messages put by LONDON or PARIS are routed to LOSANGELES or NEWYORK, with twice as many messages being sent to LOSANGELES.

This modification to the cluster was accomplished without you having to make any alterations to the queue managers LONDON and PARIS. The repositories in these queue managers are updated automatically with the information they need to be able to send messages to INVENTQ at LOSANGELES.