Choose 2 queue managers to be the full repositories for your price check cluster. We will choose REPOS1 and REPOS2 as each of these 2 queue managers. Now issue the following command:
ALTER QMGR REPOS(PRICECHECK)
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.
DEFINE CHANNEL(TO.SERVE1) CHLTYPE(CLUSRCVR) TRPTYPE(TCP) CONNAME(SERVER1.COM) CLUSTER(PRICECHECK) 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.
DEFINE CHANNEL(TO.REPOS1) CHLTYPE(CLUSSDR) TRPTYPE(TCP) CONNAME(REPOS1.COM) CLUSTER(PRICECHECK) DESCR('Cluster-sender channel to repository queue manager')
See the WebSphere MQ Application Programming Guide for information about how to do this.
Issue the following command on each:
DEFINE QLOCAL(PRICEQ) CLUSTER(PRICECHECK)
On the query queue managers we restrict the number of active channels used, by issuing the following commands on each:
ALTER QMGR CLWLMRUC(2)
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. 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:
Although there are four instances of the PRICEQ queue available in the PRICECHECK cluster, each querying queue manager only makes use of two of them. For example the QUERY1 queue manager only has active channels to the SERVER1 and SERVER2 queue managers. IF SERVER1 became unavailable, the QUERY1 queue manager would then begin to use another queue manager, for example SERVER3.
Notices |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
csqzah0770 |