Home

 

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 QCLUSTER(MORDERQ)
DIS CLUSQMGR

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

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 1. Interconnected clusters

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:

• Alter the queue manager definitions for CHICAGO and CHICAGO2, removing the REPOSNL attribute, which specifies the namelist (CHAINMAIL), and replacing it with a REPOS attribute specifying the cluster name (CHAINSTORE). For example:

  ALTER QMGR(CHICAGO) REPOSNL(' ') REPOS(CHAINSTORE)

• On each queue manager in the MAILORDER cluster, alter all the channel definitions and queue definitions to change the value of the CLUSTER attribute from MAILORDER to CHAINSTORE. For example, at HARTFORD, enter:

  ALTER CHANNEL(TO.HARTFORD) CLUSTER(CHAINSTORE)

  At OMAHA enter:

  ALTER QLOCAL(MORDERQ) CLUSTER(CHAINSTORE)

• Alter all definitions that specify the cluster namelist CHAINMAIL, that is, the CLUSRCVR and CLUSSDR channel definitions at CHICAGO, CHICAGO2, SEATTLE, and ATLANTA, to specify instead the cluster CHAINSTORE.

From this example, we can see the advantage of using namelists. Instead of altering the queue manager definitions for CHICAGO and CHICAGO2 we 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, we can achieve the required result by altering the namelist.

 

Parent topic:

Procedure

qc11960_

 

Home