Adding a queue manager that hosts a queue
Add another queue manager to the cluster, to host another INVENTQ
queue. Requests are sent alternately to the queues on each queue manager. No changes need to be made to the existing INVENTQ
host.
Before you begin
- The
INVENTORY
cluster has been set up as described in Adding a queue manager to a cluster. It contains three queue managers;LONDON
andNEWYORK
both hold full repositories, PARIS holds a partial repository. The inventory application runs on the system in New York, connected to theNEWYORK
queue manager. The application is driven by the arrival of messages on theINVENTQ
queue. - A new store is being set up in Toronto. To provide additional capacity you want to run the inventory application on the system in Toronto as well as New York.
- Network connectivity exists between all four systems.
- The network protocol is TCP.
TORONTO
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.
About this task
Procedure
Results
INVENTORY
cluster set up by this task.
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 alter the definitions on 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
. The inventory application continues to function if one of the NEWYORK
or the TORONTO
queue manager becomes unavailable, and it has sufficient capacity. The inventory application must be able to work correctly if it is hosted in both locations.
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 clustering to distribution workload evenly.
An application might not be able to process records in both locations. For example, suppose that you decide to add a customer-account query and update application running in LONDON
and NEWYORK
. An account record can only be held in one place. You could decide to control the distribution of requests by using a data partitioning technique. You can split the distribution of the records. You could arrange for half the records, for example for account numbers 00000 - 49999, to be held in LONDON
. The other half, in the range 50000 - 99999 , are held in
NEWYORK
. You could then write a cluster workload exit program to examine the account field in all messages, and route the messages to the appropriate queue manager.
What to do next
Now that you have completed all the definitions, if you have not already done so start the channel initiator on IBM® MQ for z/OS®. On all platforms, start a listener program on queue manager TORONTO
. The listener program waits for incoming network requests and starts the cluster-receiver channel when it is needed.