Before proceeding ensure that the application can handle message affinities. See Reviewing applications for message affinities for more information.
The two queue managers CHICAGO and CHICAGO2 are at the hub of this network. You have decided to concentrate all activity associated with the chainstore 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(CHAINSTORE)
At each queue manager in the cluster, define a cluster-receiver channel and a cluster-sender channel. It does not matter which of these you define first.
Make a CLUSRCVR definition to advertise each queue manager, its network address, and so on, to the cluster. For example, on queue manager ATLANTA:
DEFINE CHANNEL(TO.ATLANTA) CHLTYPE(CLUSRCVR) TRPTYPE(TCP) CONNAME(ATLANTA.CHSTORE.COM) CLUSTER(CHAINSTORE) DESCR('Cluster-receiver channel')
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(TO.CHICAGO2) CHLTYPE(CLUSSDR) TRPTYPE(TCP) CONNAME(CHICAGO2.CHSTORE.COM) CLUSTER(CHAINSTORE) DESCR('Cluster-sender channel to repository queue manager')
You already have the inventory application on queue manager CHICAGO. Now you need to make a copy of this application on queue manager CHICAGO2. Refer to the WebSphere MQ Application Programming Guide and install the inventory application on CHICAGO2.
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(CHAINSTORE)
On CHICAGO2, make a definition for the same queue:
DEFINE QLOCAL(INVENTQ) CLUSTER(CHAINSTORE)
(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. See the WebSphere MQ for z/OS System Administration Guide for details.)
When you make these definitions, a message is sent to the full repositories at CHICAGO and CHICAGO2 and the information in them is updated. From then on, when a queue manager wants to put a message to the INVENTQ, it will find out from the full repositories that there is a choice of destinations for messages sent to that queue.
Check that the definitions you created with the previous step have been propagated though the cluster by issuing the following command on a full repository queue manager:
DIS CLUSQ(INVENTQ)
Now that you have linked all your queue managers together in the CHAINSTORE cluster, and have defined the INVENTQ to the cluster, the queue managers no longer need remote-queue definitions for the INVENTQ. At every queue manager, issue the command:
DELETE QREMOTE(INVENTQ)
Until you do this, the remote-queue definitions will continue to be used and you will not get the benefit of using clusters.
Because there is more than one destination for messages sent to the INVENTQ, the workload management algorithm will determine which destination each message will be sent to.
If you want to implement your own workload management routine, write a cluster workload exit program. See Workload balancing for more information.
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 each queue manager. 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:
Remember that this diagram shows only the channels that you have to define manually. Cluster-sender channels are defined automatically when needed so that ultimately all queue managers can receive cluster information from the two full repository queue managers and also messages from the two applications.
Once again, this is a very small example, little more than a proof of concept. In your enterprise it is unlikely that you will have a cluster of this size with only one queue.
You can easily add more queues to the cluster environment by adding the CLUSTER parameter to your queue definitions, and then removing all corresponding remote-queue definitions from the other queue managers.
Notices |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
csqzah0761 |