Add a new queue manager to a cluster -- using DHCP

 

The following example makes use of the following:

  • the ability to omit the CONNAME value on a CLUSRCVR definition.

  • the ability to use +QMNAME+ on a CLUSSDR definition.

Neither of these are possible on z/OS.

Scenario

  • The INVENTORY cluster has been set up as described in Setting up a new cluster. It contains two queue managers, LONDON and AMSTERDAM, which both hold full repositories.

  • A new branch of the retail store is being set up in PARIS and you want to add a queue manager called PARIS to the cluster.

  • Queue manager PARIS will send inventory updates to the application running on the system in Amsterdam by putting messages on the RCVINVCQ queue.

  • Network connectivity exists between all three systems.

  • The network protocol is TCP.

  • The PARIS queue manager system uses DHCP, which means that the IP addresses may change on system restart.

  • The channels between the PARIS and LONDON systems are named according to a defined naming convention, which involves the queue manager name of the full repository queue manager on LONDON.

  • Administrators of the PARIS queue manager have no information about the name of the queue manager on the LONDON repository, or the name of the queue manager on the LONDON repository is subject to change.

 

1. Determine which full repository PARIS should refer to first

This is the same as for task 2a.

 

2. Define a CLUSRCVR channel on queue manager PARIS

Every queue manager in a cluster needs to define a cluster-receiver channel on which it can receive messages. On PARIS, define: 

DEFINE CHANNEL(TO.PARIS) CHLTYPE(CLUSRCVR) 
TRPTYPE(TCP) CLUSTER(INVENTORY)
DESCR('Cluster-receiver channel for queue manager PARIS')

This advertises the queue manager's availability to receive messages from other queue managers in the cluster INVENTORY. There is no need to specify the CONNAME, you can request WebSphere MQ to find out the connection name from the system either by omitting CONNAME, or by specifying CONNAME(' '). WebSphere MQ generates the CONNAME value using the current IP address of the system. There is no need to make definitions on other queue managers for a sending end to the cluster-receiver channel TO.PARIS. These will be made automatically when needed.

 

3. Define a CLUSSDR channel on queue manager PARIS

Every queue manager in a cluster needs to define one cluster-sender channel on which it can send messages to its initial full repository. On PARIS, make the following definition for a channel called TO.+QMNAME+ to the queue manager whose network address is LONDON.CHSTORE.COM. 

DEFINE CHANNEL(TO.+QMNAME+) CHLTYPE(CLUSSDR) TRPTYPE(TCP)
CONNAME(LONDON.CHSTORE.COM) CLUSTER(INVENTORY)
DESCR('Cluster-sender channel from PARIS to repository at LONDON')

 

The cluster achieved by task 2b

The cluster set up by this task is the same as for task 2a.

By making only two definitions, a CLUSRCVR definition and a CLUSSDR definition, we have added the queue manager PARIS to the cluster.

On the PARIS queue manager, the CLUSSDR containing the string +QMNAME+ starts. On the LONDON system WebSphere MQ resolves the +QMNAME+ to the queue manager name (LONDON). WebSphere MQ then matches the definition for a channel called TO.LONDON to the corresponding CLUSRCVR definition.

WebSphere MQ sends back the resolved channel name to the PARIS queue manager. At PARIS, the CLUSSDR channel definition for the channel called TO.+QMNAME+ is replaced by an internally-generated CLUSSDR definition for TO.LONDON. This definition contains the resolved channel name, but otherwise is the same as the +QMNAME+ definition that you made. The cluster repositories are also brought up-to-date with the channel definition with the newly-resolved channel name.

Notes:

  1. The channel created with the +QMNAME+ name becomes inactive immediately. It is never used to transmit data.

  2. Channel exits may see the channel name change between one invocation and the next.

Now the PARIS queue manager learns, from the repository at LONDON, that the RCVINVCQ queue is hosted by queue manager AMSTERDAM. When an application hosted by the system in PARIS tries to put messages to the RCVINVCQ, PARIS automatically defines a cluster-sender channel to connect to the cluster-receiver channel TO.AMSTERDAM. The application can receive responses when its queue-manager name is specified as the target queue manager and a reply-to queue is provided.

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.