Add a new queue manager that hosts a queue
Scenario
- An INVENTORY cluster has been set up which contains three queue managers:
LONDON Full repository AMSTERDAM Full repository PARIS Partial repository - The inventory application runs on the system in Amsterdam, connected to the AMSTERDAM queue manager.The application is driven by the arrival of messages on the RCVINVCQ queue.
- A new store is being set up in Paris. To provide additional capacity you want to run the inventory application on the system in Paris as well as Amsterdam.
- Network connectivity exists between all four systems.
- The network protocol is TCP.
The queue manager PARIS contains only a partial repository. If you want to add a full-repository queue manager to a cluster, refer to Moving a full repository to another queue manager.
1. Determine which full repository PARIS 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 AMSTERDAM. 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 messages. On PARIS, define:
DEFINE CHANNEL(TO.PARIS) + CHLTYPE(CLUSRCVR) + TRPTYPE(TCP) + CONNAME(PARIS.CHSTORE.COM) + CLUSTER(INVENTORY) + DESCR('Cluster-receiver channel for PARIS')This advertises the queue manager's availability to receive messages from other queue managers in the cluster, INVENTORY.
3. Define a CLUSSDR channel on queue manager PARIS
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 AMSTERDAM, so PARIS needs the following definition:
DEFINE CHANNEL(TO.AMSTERDAM) + CHLTYPE(CLUSSDR) + TRPTYPE(TCP) + CONNAME(AMSTERDAM.CHSTORE.COM) + CLUSTER(INVENTORY) + DESCR('Cluster-sender channel from PARIS to repository at AMSTERDAM')
4. 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.
5. Install the inventory application on the system in Paris
See the WebSphere MQ Application Programming Guide for information about how to do this.
6. Define the cluster queue RCVINVCQ
The RCVINVCQ queue, which is already hosted by the AMSTERDAM queue manager, is also to be hosted by PARIS. Define it on the PARIS queue manager as follows:
DEFINE QLOCAL(RCVINVCQ) + CLUSTER(INVENTORY)Now that you have completed all the definitions, if you have not already done so start the channel initiator on WebSphere MQ for z/OS and, on all platforms, start a listener program on queue manager PARIS. 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 achieved by task 3
The RCVINVCQ queue and the 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 RCVINVCQ by either PARIS or AMSTERDAM are handled by the instance on the local queue manager whenever possible. Messages put by LONDON or PARIS are routed alternately to PARIS or AMSTERDAM, so that the workload is balanced.
This modification to the cluster was accomplished without you having to make any alterations to the queue managers AMSTERDAM, LONDON, and PARIS. The full repositories in these queue managers are updated automatically with the information they need to be able to send messages to RCVINVCQ at PARIS.
Assuming that the inventory application is designed appropriately and that there is sufficient processing capacity on the systems in Amsterdam and Paris, the inventory application will continue to function if either the AMSTERDAM or the PARIS queue manager becomes unavailable.
Extensions to this task
As you can see from the result of this task, you can have the same application running on more than one queue manager. You can use the facility to allow even distribution of your workload, or you may decide to control the distribution yourself by using a data partitioning technique.
For example, suppose that you decide to add a customer-account query and update application running in LONDON and AMSTERDAM. Account information can only be held in one place, but you could arrange for half the records, for example for account numbers 00000 to 49999, to be held in LONDON, and the other half, in the range 50000 to 99999, to be held in AMSTERDAM. Write a cluster workload exit program to examine the account field in all messages, and route the messages to the appropriate queue manager.
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.