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 on WebSphere MQ for z/OS 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 1. The INVENTORY cluster with four queue managers
The INVENTQ 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 INVENTQ by either TORONTO or NEWYORK are handled by the instance on the local queue manager whenever possible. Messages put by LONDON or PARIS are routed alternately to TORONTO or NEWYORK, so that the workload is balanced.
This modification to the cluster was accomplished without you having to make any alterations to the queue managers NEWYORK, 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 INVENTQ at TORONTO.
Assuming that the inventory application is designed appropriately and that there is sufficient processing capacity on the systems in New York and Toronto, the inventory application will continue to function if either the NEWYORK or the TORONTO queue manager becomes unavailable.
As we can see from the result of this task, we can have the same application running on more than one queue manager. We 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 NEWYORK. 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 NEWYORK. Write a cluster workload exit program to examine the account field in all messages, and route the messages to the appropriate queue manager.
Parent topic:
Procedure
qc11570_
Home
