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 NEWYORK. Once the new queue manager has joined the cluster it will communicate with both of the repositories.
Every queue manager in a cluster needs to define a cluster-receiver on which it can receive messages. This queue manager needs to be able to communicate on each network.
DEFINE CHANNEL(TO.EDINBURGH.NETA) CHLTYPE(CLUSRCVR) TRPTYPE(TCP) CONNAME('EDINBURGH.NETA.CMSTORE.COM') CLUSTER(INVENTORY) DESCR('Cluster-receiver channel using network A for EDINBURGH')
DEFINE CHANNEL(TO.EDINBURGH.NETB) CHLTYPE(CLUSRCVR) TRPTYPE(TCP) CONNAME('EDINBURGH.NETB.CMSTORE.COM') CLUSTER(INVENTORY) DESCR('Cluster-receiver channel using network Bfor EDINBURGH')
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 NEWYORK, so EDINBURGH needs the following definition:
DEFINE CHANNEL(TO.NEWYORK) CHLTYPE(CLUSSDR) TRPTYPE(TCP) CONNAME(NEWYORK.CHSTORE.COM) CLUSTER(INVENTORY) DESCR('Cluster-sender channel from EDINBURGH to repository at NEWYORK')
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 set up by this task looks like this:
By making only three definitions, we have added the queue manager EDINBURGH to the cluster with two different network routes available to it.
Notices |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
csqzah0767 |