Procedure

1. Create a namelist of the cluster names

The full repository queue managers at CHICAGO and CHICAGO2 are now going to hold the full repositories for both of the clusters CHAINSTORE and MAILORDER. First, create a namelist containing the names of the clusters. Define the namelist on CHICAGO and CHICAGO2, as follows:

DEFINE NAMELIST(CHAINMAIL)
       DESCR('List of cluster names')
       NAMES(CHAINSTORE, MAILORDER)

2. Alter the two queue-manager definitions

Now alter the two queue-manager definitions at CHICAGO and CHICAGO2. Currently these definitions show that the queue managers hold full repositories for the cluster CHAINSTORE. Change that definition to show that the queue managers hold full repositories for all clusters listed in the CHAINMAIL namelist. To do this, at both CHICAGO and CHICAGO2, specify:

ALTER QMGR REPOS(' ') REPOSNL(CHAINMAIL)

3. Alter the CLUSRCVR channels on CHICAGO and CHICAGO2

The CLUSRCVR channel definitions at CHICAGO and CHICAGO2 show that the channels are available in the cluster CHAINSTORE. You need to change this to show that the channels are available to all clusters listed in the CHAINMAIL namelist. To do this, at CHICAGO, enter the command:

ALTER CHANNEL(TO.CHICAGO) CHLTYPE(CLUSRCVR)
      CLUSTER(' ') CLUSNL(CHAINMAIL)

At CHICAGO2, enter the command:

ALTER CHANNEL(TO.CHICAGO2) CHLTYPE(CLUSRCVR)
      CLUSTER(' ') CLUSNL(CHAINMAIL)

4. Alter the CLUSSDR channels on CHICAGO and CHICAGO2

Change the two CLUSSDR channel definitions to add the namelist. At CHICAGO, enter the command:

ALTER CHANNEL(TO.CHICAGO2) CHLTYPE(CLUSSDR)
      CLUSTER(' ') CLUSNL(CHAINMAIL)

At CHICAGO2, enter the command:

ALTER CHANNEL(TO.CHICAGO) CHLTYPE(CLUSSDR)
      CLUSTER(' ') CLUSNL(CHAINMAIL)

5. Create a namelist on SEATTLE and ATLANTA

Because SEATTLE and ATLANTA are going to be members of more than one cluster, you must create a namelist containing the names of the clusters. Define the namelist on SEATTLE and ATLANTA, as follows:

DEFINE NAMELIST(CHAINMAIL)
       DESCR('List of cluster names')
       NAMES(CHAINSTORE, MAILORDER)

6. Alter the CLUSRCVR channels on SEATTLE and ATLANTA

The CLUSRCVR channel definitions at SEATTLE and ATLANTA show that the channels are available in the cluster CHAINSTORE. Change this to show that the channels are available to all clusters listed in the CHAINMAIL namelist. To do this, at SEATTLE, enter the command:

ALTER CHANNEL(TO.SEATTLE) CHLTYPE(CLUSRCVR)
      CLUSTER(' ') CLUSNL(CHAINMAIL)

At ATLANTA, enter the command:

ALTER CHANNEL(TO.ATLANTA) CHLTYPE(CLUSRCVR)
      CLUSTER(' ') CLUSNL(CHAINMAIL)

7. Alter the CLUSSDR channels on SEATTLE and ATLANTA

Change the two CLUSSDR channel definitions to add the namelist. At SEATTLE, enter the command:

ALTER CHANNEL(TO.CHICAGO) CHLTYPE(CLUSSDR)
      CLUSTER(' ') CLUSNL(CHAINMAIL)

At ATLANTA, enter the command:

ALTER CHANNEL(TO.CHICAGO2) CHLTYPE(CLUSSDR)
      CLUSTER(' ') CLUSNL(CHAINMAIL)

8. Define CLUSRCVR and CLUSSDR channels on HARTFORD and OMAHA

On the two new queue managers HARTFORD and OMAHA, define cluster-receiver and cluster-sender channels. It doesn't matter in which sequence you do this. At HARTFORD, enter:

DEFINE CHANNEL(TO.HARTFORD) CHLTYPE(CLUSRCVR) TRPTYPE(TCP)
CONNAME(HARTFORD.CHSTORE.COM) CLUSTER(MAILORDER)
DESCR('Cluster-receiver channel for HARTFORD')
 
DEFINE CHANNEL(TO.CHICAGO) CHLTYPE(CLUSSDR) TRPTYPE(TCP)
CONNAME(CHICAGO.CHSTORE.COM) CLUSTER(MAILORDER)
DESCR('Cluster-sender channel from HARTFORD to repository at CHICAGO')

At OMAHA, enter:

DEFINE CHANNEL(TO.OMAHA) CHLTYPE(CLUSRCVR) TRPTYPE(TCP)
CONNAME(OMAHA.CHSTORE.COM) CLUSTER(MAILORDER)
DESCR('Cluster-receiver channel for OMAHA')
 
DEFINE CHANNEL(TO.CHICAGO) CHLTYPE(CLUSSDR) TRPTYPE(TCP)
CONNAME(CHICAGO.CHSTORE.COM) CLUSTER(MAILORDER)
DESCR('Cluster-sender channel from OMAHA to repository at CHICAGO')

9. Define the MORDERQ queue on OMAHA

The final step to complete this task is to define the queue MORDERQ on the queue manager OMAHA. To do this, enter:

DEFINE QLOCAL(MORDERQ) CLUSTER(MAILORDER)

10. Check that the cluster changes have been propagated

Check that the definitions you created with the previous steps have been propagated though the cluster by issuing the following commands on a full repository queue manager:

DIS CLUSQ(MORDERQ)
DIS CLUSQMGR

The cluster set up by this task is shown in Figure 21.

Now we have two overlapping clusters. The full repositories for both clusters are held at CHICAGO and CHICAGO2. The mailorder application that runs on OMAHA is independent of the inventory application that runs at CHICAGO. However, some of the queue managers that are in the CHAINSTORE cluster are also in the MAILORDER cluster, and so they can send messages to either application. Before carrying out this task to overlap two clusters, be aware of the possibility of queue-name clashes. Suppose that on NEWYORK in cluster CHAINSTORE and on OMAHA in cluster MAILORDER, there is a queue called ACCOUNTQ. If you overlap the clusters and then an application on a queue manager that is a member of both clusters, for example SEATTLE, puts a message to the queue ACCOUNTQ, the message can go to either instance of the ACCOUNTQ.

Figure 21. Interconnected clusters
Interconnected clusters is described in the preceding text.

Suppose you decide to merge the MAILORDER cluster with the CHAINSTORE cluster to form one large cluster called CHAINSTORE.

To merge the MAILORDER cluster with the CHAINSTORE cluster, such that CHICAGO and CHICAGO2 hold the full repositories:

From this example, you can see the advantage of using namelists. Instead of altering the queue manager definitions for CHICAGO and CHICAGO2 you can just alter the value of the namelist CHAINMAIL. Similarly, instead of altering the CLUSRCVR and CLUSSDR channel definitions at CHICAGO, CHICAGO2, SEATTLE, and ATLANTA, you can achieve the required result by altering the namelist.