Adding a queue manager to a cluster by using DHCP

Add a queue manager to a cluster, using DHCP. The task demonstrates omitting CONNAME value on a CLUSRCVR definition.

Before you begin

Note: For changes to a cluster to be propagated throughout the cluster, at least one full repository must always be available. Ensure that your repositories are available before starting this task.
The task demonstrates two special features:
  • The ability to omit the CONNAME value on a CLUSRCVR definition.
  • The ability to use +QMNAME+ on a CLUSSDR definition.
Neither feature is provided 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 NEWYORK, which both hold full repositories.
  • A new branch of the chain store is being set up in Paris and you want to add a queue manager called PARIS to the cluster.
  • Queue manager PARIS sends inventory updates to the application running on the system in New York by putting messages on the INVENTQ 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 might change on system restart.
  • The channels between the PARIS and LONDON systems are named according to a defined naming convention. The convention uses 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. The name of the queue manager on the LONDON repository is subject to change.

About this task

Follow these steps to add a queue manager to a cluster by using DHCP.

Procedure

  1. Decide which full repository PARIS refers to first.

    Every queue manager in a cluster must refer to one or other of the full repositories. It gathers information about the cluster from a full repository and so builds up its own partial repository. Choose either of the repositories as the full repository. As soon as a new queue manager is added to the cluster it immediately learns about the other repository as well. Information about changes to a queue manager is sent directly to two repositories. In this example we choose to link PARIS to the queue manager LONDON, purely for geographical reasons.

    Note: Perform the remaining steps in any order, after queue manager PARIS is started.
  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(INVENTORY.PARIS) CHLTYPE(CLUSRCVR)
TRPTYPE(TCP) CLUSTER(INVENTORY)
DESCR('Cluster-receiver channel for queue manager PARIS')

    The cluster-receiver channel advertises the availability of the queue manager to receive messages from other queue managers in the cluster INVENTORY. You do not need to specify the CONNAME on the cluster-receiver channel. You can request IBM® MQ to find out the connection name from the system, either by omitting CONNAME, or by specifying CONNAME(' '). IBM MQ generates the CONNAME value using the current IP address of the system; see CONNAME . There is no need to make definitions on other queue managers for a sending end to the cluster-receiver channel INVENTORY.PARIS. Other definitions are 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 INVENTORY.+QMNAME+ to the queue manager with the network address LONDON.CHSTORE.COM. 
    
DEFINE CHANNEL(INVENTORY.+QMNAME+) CHLTYPE(CLUSSDR) TRPTYPE(TCP)
CONNAME(LONDON.CHSTORE.COM) CLUSTER(INVENTORY)
DESCR('Cluster-sender channel from PARIS to repository at LONDON')
  4. Optional: If you are adding to a cluster a queue manager that has previously been removed from the same cluster, check that it is now showing as a cluster member. If not, complete the following extra steps:
    1. Issue the REFRESH CLUSTER command on the queue manager you are adding.
      This step stops the cluster channels, and gives your local cluster cache a fresh set of sequence numbers that are assured to be up-to-date within the rest of the cluster. 
      
REFRESH CLUSTER(INVENTORY) REPOS(YES)
      Note: For large clusters, using the REFRESH CLUSTER command can be disruptive to the cluster while it is in progress, and again at 27 day intervals thereafter when the cluster objects automatically send status updates to all interested queue managers. See Refreshing in a large cluster can affect performance and availability of the cluster.
    2. Restart the CLUSSDR channel
      (for example, using the START CHANNEL command).
    3. Restart the CLUSRCVR channel.

Results

The cluster set up by this task is the same as for Adding a queue manager to a cluster:

Figure 1. The INVENTORY cluster with three queue managers
The diagram shows a cluster with three connected queues, LONDON, NEW YORK, and PARIS. NEW YORK has a queue called INVENTQ.

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 IBM MQ resolves the +QMNAME+ to the queue manager name ( LONDON). IBM MQ then matches the definition for a channel called INVENTORY.LONDON to the corresponding CLUSRCVR definition.

IBM MQ sends back the resolved channel name to the PARIS queue manager. At PARIS, the CLUSSDR channel definition for the channel called INVENTORY.+QMNAME+ is replaced by an internally generated CLUSSDR definition for INVENTORY.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.

Note:
  1. The channel created with the +QMNAME+ name becomes inactive immediately. It is never used to transmit data.
  2. Channel exits might see the channel name change between one invocation and the next.

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