Procedure

Perform the following tasks at the TORONTO queue manager:

1. Modify the full repository queue manager REPOS and REPOSNL attributes

If your queue manager is a full repository queue manager, before you can remove it from a cluster, perform the additional step of altering the queue manager definition to set the REPOS and REPOSNL attributes to blank. This sends a notification to other queue managers advising them that they must stop sending cluster information to this queue manager.

2. Check that the REPOS and REPOSNL changes have been propagated

Check that the changes you made in the previous step have been propagated around the cluster by issuing the following command on a remaining full repository:

DIS CLUSQMGR(TORONTO) QMTYPE

and check that it shows that the queue manager is no longer a full repository. The output should match the following:

AMQ8441: Display Cluster Queue Manager details.
   CLUSQMGR(TORONTO)                       CLUSTER(INVENTORY)
   CHANNEL(TO.TORONTO)                     QMTYPE(NORMAL)

3. Suspend queue manager TORONTO

Issue the SUSPEND QMGR command to suspend availability of the queue manager to the INVENTORY cluster:

SUSPEND QMGR CLUSTER(INVENTORY)

When you issue this command, other queue managers are advised that they should refrain from sending messages to TORONTO.

4. Check that queue manager TORONTO has been suspended

Check that TORONTO has been suspended before moving on to the next step by issuing the following command on a full repository:

DIS CLUSQMGR(TORONTO) SUSPEND

and check that it shows that the queue manager is suspended. The output should match the following:

AMQ8441: Display Cluster Queue Manager details.
   CLUSQMGR(TORONTO)                       CLUSTER(INVENTORY)
   CHANNEL(TO.TORONTO)                     SUSPEND(YES)

5. Remove the CLUSRCVR channel definition

Remove the CLUSRCVR definition from the cluster:

ALTER CHANNEL(TO.TORONTO) CHLTYPE(CLUSRCVR) CLUSTER(' ')

This command causes the full repository queue managers to remove all information about that channel from their full repositories, so that queue managers will no longer try to send messages to it. You can verify that this command has been successfully propagated by issuing the following command on the full repository:

DIS CLUSQMGR(TORONTO)

You should receive a message like that below:

AMQ8147: WebSphere MQ object TORONTO not found

6. Stop the CLUSRCVR channel at TORONTO

Note:
Before performing this step, ensure that any bound messages have arrived on TORONTO, otherwise these messages will become stuck on the sending queue manager's cluster transmit queue.

Issue the STOP CHANNEL command to stop the cluster-receiver channel:

STOP CHANNEL(TO.TORONTO)

Once the channel is stopped, no more messages can be sent to TORONTO.

Later, to tidy up, you will probably want to delete the channel:

DELETE CHANNEL(TO.TORONTO)

Note:
At this point the TORONTO queue manager is no longer a valid destination in the cluster, but there may be messages bound to TORONTO (messages put using BIND_ON_OPEN) still being sent from other queue managers in the cluster.

7. Delete the CLUSSDR channel definition

Note:
Do not attempt this step before completing all previous steps in this task.

The CLUSSDR channel definition points to the full repository at queue manager NEWYORK. Stop this channel as follows:

STOP CHANNEL(TO.NEWYORK)

and then delete it:

DELETE CHANNEL(TO.NEWYORK)

8. Issue the REFRESH CLUSTER command

Issue the REFRESH CLUSTER command to remove any auto-defined cluster channels:

REFRESH CLUSTER(INVENTORY) REPOS(YES)

The cluster set up by this task looks like this:

Figure 23. The INVENTORY cluster, with TORONTO outside the cluster
The diagram shows the INVENTORY cluster, with NEW YORK, LONDON and PARIS connected inside the cluster and TORONTO outside the cluster. NEW YORK and LONDON are still hosting the inventory application, and NEW YORK is still hosting the INVENTQ.

The queue manager TORONTO is no longer part of the cluster. However, it can still function as an independent queue manager.

This modification to the cluster was accomplished without you having to make any alterations to the queue managers NEWYORK, LONDON, and PARIS.

Queue sharing groups behavior: On z/OS, if the queue manager you remove from a cluster has queues that belong to a queue sharing group, it can still process messages put to the shared queues as normal.

For example, suppose a cluster consists of the following 4 queue managers:

In this cluster, the cluster queues belong to a queue sharing group:

The cluster set up by this task looks like this:

Figure 24. Queue sharing group
The diagram shows a queue sharing group

In this cluster, you process a number of messages to completion as a benchmark. Then, to take one of the queue managers holding a partial repository out of the cluster, you:

When you reprocess the same messages as a test, the queue manager that was removed from the cluster is still able to process messages put to the shared queues.