Removing a cluster network

Remove a cluster from a network and restore the distributed queuing configuration.

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.
Scenario:
  • An IBM® WebSphere® MQ cluster has been set up as described in Converting an existing network into a cluster.
  • This cluster is now to be removed from the system. The network of queue managers is to continue functioning as it did before the cluster was implemented.

About this task

Follow these steps to remove a cluster network.

Procedure

  1. Remove cluster queues from the CHNSTORE cluster.
    On both CHICAGO and CHICAGO2, modify the local queue definition for the queue INVENTQ to remove the queue from the cluster. Issue the command:
    ALTER QLOCAL(INVENTQ) CLUSTER(' ')

    When you alter the queue, the information in the full repositories is updated and propagated throughout the cluster. Active applications using MQOO_BIND_NOT_FIXED, and applications using MQOO_BIND_AS_Q_DEF where the queue has been defined with DEFBIND(NOTFIXED), fail on the next attempted MQPUT or MQPUT1 call. The reason code MQRC_UNKNOWN_OBJECT_NAME is returned.

    You do not have to perform Step 1 first, but if you do not, perform it instead after Step 4.

  2. Stop all applications that have access to cluster queue.

    Stop all applications that have access to cluster queues. If you do not, some cluster information might remain on the local queue manager when you refresh the cluster in Step 5. This information is removed when all applications have stopped and the cluster channels have disconnected.

  3. Remove the repository attribute from the full repository queue managers.
    On both CHICAGO and CHICAGO2, modify the queue manager definitions to remove the repository attribute. To do this issue the command:
    
    ALTER QMGR REPOS(' ')

    The queue managers inform the other queue managers in the cluster that they no longer hold the full repositories. When the other queue managers receive this information, you see a message indicating that the full repository has ended. You also see one or more messages indicating that there are no longer any repositories available for the cluster CHNSTORE .

  4. Remove cluster channels.
    On CHICAGO remove the cluster channels:
    ALTER CHANNEL(CHNSTORE.CHICAGO2) CHLTYPE(CLUSSDR) CLUSTER(' ')
    ALTER CHANNEL(CHNSTORE.CHICAGO) CHLTYPE(CLUSRCVR) CLUSTER(' ')
    Note: It is important to issue the CLUSSDR command first, then CLUSRCVR command. Do not issue the CLUSRCVR command first, then the CLUSSDR command. Doing so, creates indoubt channels that have a STOPPED status. You then need to issue a START CHANNEL command to recover the stopped channels; for example, START CHANNEL(CHNSTORE.CHICAGO).

    You see messages indicating that there are no repositories for the cluster CHNSTORE.

    If you did not remove the cluster queues as described in Step 1, do so now.

  5. Stop cluster channels.
    On CHICAGO stop the cluster channels with the following commands:
    
    STOP CHANNEL(CHNSTORE.CHICAGO2) 
    STOP CHANNEL(CHNSTORE.CHICAGO)
  6. Repeat steps 4 and 5 for each queue manager in the cluster.
  7. Stop the cluster channels, then remove all definitions for the cluster channels and cluster queues from each queue manager.
  8. Optional: Clear the cached cluster information held by the queue manager.
    Although the queue managers are no longer members of the cluster, they each retain a cached copy of information about the cluster. If you want to remove this data, see task Restoring a queue manager to its pre-cluster state.
  9. Replace the remote-queue definitions for the INVENTQ

    So that the network can continue to function, replace the remote queue definition for the INVENTQ at every queue manager.

  10. Tidy up the cluster.

    Delete any queue or channel definitions no longer required.