Converting an existing network into a cluster

Convert an existed distributed queuing network to a cluster and add an additional queue manager to increase capacity.

Before you begin

In Setting up a new cluster through Moving a full repository to another queue manager you created and extended a new cluster. The next two tasks explore a different approach: that of converting an existing network of queue managers into a cluster.

Note: For changes to a cluster to be propagated throughout the cluster, at least one full repository must always be available. Ensure that your repositories are available before starting this task.

Scenario:

An IBM® WebSphere® MQ network is already in place, connecting the nationwide branches of a chain store. It has a hub and spoke structure: all the queue managers are connected to one central queue manager. The central queue manager is on the system on which the inventory application runs. The application is driven by the arrival of messages on the INVENTQ queue, for which each queue manager has a remote-queue definition.
This network is illustrated in Figure 1.
Figure 1. A hub and spoke network
To ease administration you are going to convert this network into a cluster and create another queue manager at the central site to share the workload.
The cluster name is CHNSTORE.

Note: The cluster name CHNSTORE was selected to allow cluster-receiver channel names to be created using names in the format cluster-name.queue-manager that do not exceed the maximum length of 20 characters, for example CHNSTORE.WASHINGTON.
Both the central queue managers are to host full repositories and be accessible to the inventory application.
The inventory application is to be driven by the arrival of messages on the INVENTQ queue hosted by either of the central queue managers.
The inventory application is to be the only application running in parallel and accessible by more than one queue manager. All other applications continue to run as before.
All the branches have network connectivity to the two central queue managers.
The network protocol is TCP.

About this task

Follow these steps to convert an existing network into a cluster.

Procedure

Review the inventory application for message affinities.
Before proceeding ensure that the application can handle message affinities. Message affinities are the relationship between conversational messages that are exchanged between two applications, where the messages must be processed by a particular queue manager or in a particular sequence. For more information on message affinities, see: Handling message affinities
Alter the two central queue managers to make them full repository queue managers.
The two queue managers CHICAGO and CHICAGO2 are at the hub of this network. You have decided to concentrate all activity associated with the chain store cluster on to those two queue managers. As well as the inventory application and the definitions for the INVENTQ queue, you want these queue managers to host the two full repositories for the cluster. At each of the two queue managers, issue the following command:
```
ALTER QMGR REPOS(CHNSTORE)
```
Define a CLUSRCVR channel on each queue manager.
At each queue manager in the cluster, define a cluster-receiver channel and a cluster-sender channel. It does not matter which channel you define first.
Make a CLUSRCVR definition to advertise each queue manager, its network address, and other information, to the cluster. For example, on queue manager ATLANTA:
```
DEFINE CHANNEL(CHNSTORE.ATLANTA) CHLTYPE(CLUSRCVR) TRPTYPE(TCP)
CONNAME(ATLANTA.CHSTORE.COM) CLUSTER(CHNSTORE)
DESCR('Cluster-receiver channel')
```
Define a CLUSSDR channel on each queue manager
Make a CLUSSDR definition at each queue manager to link that queue manager to one or other of the full repository queue managers. For example, you might link ATLANTA to CHICAGO2:
```
DEFINE CHANNEL(CHNSTORE.CHICAGO2) CHLTYPE(CLUSSDR) TRPTYPE(TCP)
CONNAME(CHICAGO2.CHSTORE.COM) CLUSTER(CHNSTORE)
DESCR('Cluster-sender channel to repository queue manager')
```
Install the inventory application on CHICAGO2.
You already have the inventory application on queue manager CHICAGO. Now you need to make a copy of this application on queue manager CHICAGO2.
Define the INVENTQ queue on the central queue managers.
On CHICAGO, modify the local queue definition for the queue INVENTQ to make the queue available to the cluster. Issue the command:
```
ALTER QLOCAL(INVENTQ) CLUSTER(CHNSTORE)
```
On CHICAGO2, make a definition for the same queue:
```
DEFINE QLOCAL(INVENTQ) CLUSTER(CHNSTORE)
```
On z/OS®, you can use the MAKEDEF option of the COMMAND function of CSQUTIL to make an exact copy on CHICAGO2 of the INVENTQ on CHICAGO.

When you make these definitions, a message is sent to the full repositories at CHICAGO and CHICAGO2 and the information in them is updated. The queue manager finds out from the full repositories when it puts a message to the INVENTQ, that there is a choice of destinations for the messages.
Check that the cluster changes have been propagated.
Check that the definitions you created in the previous step have been propagated though the cluster. Issue the following command on a full repository queue manager:
```
DIS QCLUSTER(INVENTQ)
```