Queue Manager Clusters: WebSphere MQ commands for work with clusters

WebSphere MQ commands for work with clusters

This section introduces MQSC commands that apply specifically to work with WebSphere MQ clusters:

DISPLAY CLUSQMGR
SUSPEND QMGR
RESUME QMGR
REFRESH CLUSTER
RESET CLUSTER

The PCF equivalents to these commands are:

MQCMD_INQUIRE_CLUSTER_Q_MGR
MQCMD_SUSPEND_Q_MGR_CLUSTER
MQCMD_RESUME_Q_MGR_CLUSTER
MQCMD_REFRESH_CLUSTER
MQCMD_RESET_CLUSTER

DISPLAY CLUSQMGR

Use the DISPLAY CLUSQMGR command to display cluster information about queue managers in a cluster. If you issue this command from a queue manager with a full repository, the information returned pertains to every queue manager in the cluster. If you issue this command from a queue manager that does not have a full repository, the information returned pertains only to the queue managers in which it has an interest. That is, every queue manager to which it has tried to send a message and every queue manager that holds a full repository.
The information includes most channel attributes that apply to cluster-sender and cluster-receiver channels, such as:

DEFTYPE How the queue manager was defined. DEFTYPE can be one of the following:

CLUSSDR

Defined explicitly as a cluster-sender channel

CLUSSDRA

Defined by auto-definition as a cluster-sender channel

CLUSSDRB

Defined as a cluster-sender channel, both explicitly and by auto-definition

CLUSRCVR

Defined as a cluster-receiver channel

QMTYPE Whether it holds a full repository or only a partial repository.

CLUSDATE The date at which the definition became available to the local queue manager.

CLUSTIME The time at which the definition became available to the local queue manager.

STATUS The current status of the cluster-sender channel for this queue manager.

SUSPEND Whether the queue manager is suspended.

CLUSTER What clusters the queue manager is in.

CHANNEL The cluster-receiver channel name for the queue manager.

SUSPEND QMGR and RESUME QMGR

Use the SUSPEND QMGR command and RESUME QMGR command to remove a queue manager from a cluster temporarily, for example for maintenance, and then to reinstate it. Use of these commands is discussed in Maintaining a queue manager.

REFRESH CLUSTER

You are unlikely to need to use this command, except in exceptional circumstances. Issue the REFRESH CLUSTER command from a queue manager to discard all locally held information about a cluster.
There are two forms of this command using the REPOS parameter.
Using REFRESH CLUSTER(clustername) REPOS(NO) provides the default behavior. The queue manager will retain knowledge of all cluster queue manager and cluster queues marked as locally defined and all cluster queue managers that are marked as full repositories. In addition, if the queue manager is a full repository for the cluster it will also retain knowledge of the other cluster queue managers in the cluster. Everything else will be removed from the local copy of the repository and rebuilt from the other full repositories in the cluster. Cluster channels will not be stopped if REPOS(NO) is used, a full repository will use its CLUSSDR channels to inform the rest of the cluster that it has completed its refresh.
Using REFRESH CLUSTER(clustername) REPOS(YES) specifies that in addition to the default behavior, objects representing full repository cluster queue managers are also refreshed. This option may not be used if the queue manager is itself a full repository. If it is a full repository, you must first alter it so that it is not a full repository for the cluster in question. The full repository location will be recovered from the manually defined CLUSSDR definitions. After the refresh with REPOS(YES) has been issued the queue manager can be altered so that it is once again a full repository, if required.
You can issue REFRESH CLUSTER(*). This refreshes the queue manager in all of the clusters it is a member of. If used with REPOS(YES) this has the additional effect of forcing the queue manager to restart its search for full repositories from the information in the local CLUSSDR definitions, even if the CLUSSDR connects the queue manager to several clusters.
For information on resolving problems with the REFRESH CLUSTER command see Resolving Problems.

RESET CLUSTER

You are unlikely to need to use this command, except in exceptional circumstances. Use the RESET CLUSTER command to forcibly remove a queue manager from a cluster. You can do this from a full repository queue manager by issuing either the command:
RESET CLUSTER(clustername) QMNAME(qmname) ACTION(FORCEREMOVE)  QUEUES(NO)
or the command:
RESET CLUSTER(clustername) QMID(qmid) ACTION(FORCEREMOVE)  QUEUES(NO)
You cannot specify both QMNAME and QMID.
Specifying QUEUES(NO) on a RESET CLUSTER command is the default. Specifying QUEUES(YES) means that reference to cluster queue or queues owned by the queue manager being force removed are removed from the cluster in addition to the cluster queue manager itself. The cluster queues are removed even if the cluster queue manager is not visible in the cluster, perhaps because it was previously force removed without the QUEUES option.
You might use the RESET CLUSTER command if, for example, a queue manager has been deleted but still has cluster-receiver channels defined to the cluster. Instead of waiting for WebSphere MQ to remove these definitions (which it does automatically) you can issue the RESET CLUSTER command to tidy up sooner. All other queue managers in the cluster are then informed that the queue manager is no longer available.
In an emergency where a queue manager is temporarily damaged, you might want to inform the rest of the cluster before the other queue managers try to send it messages. RESET CLUSTER can be used to remove the damaged queue manager. Later when the damaged queue manager is working again, you can use the REFRESH CLUSTER command to reverse the effect of RESET CLUSTER and put it back in the cluster again.
Using the RESET CLUSTER command is the only way to delete auto-defined cluster-sender channels. You are unlikely to need this command in normal circumstances, but your IBM^(R) Support Center might advise you to issue the command to tidy up the cluster information held by cluster queue managers. Do not use this command as a short cut to removing a queue manager from a cluster. The correct way to do this is described in Removing a queue manager from a cluster.
You can issue the RESET CLUSTER command only from full repository queue managers.
If you use QMNAME, and there is more than one queue manager in the cluster with that name, the command is not actioned. Use QMID instead of QMNAME to ensure the RESET CLUSTER command is actioned.
Because repositories retain information for only 90 days, after that time a queue manager that was forcibly removed can reconnect to a cluster. It does this automatically (unless it has been deleted). If you want to prevent a queue manager from rejoining a cluster, you need to take appropriate security measures. See Preventing queue managers joining a cluster.
All cluster commands (except DISPLAY CLUSQMGR) work asynchronously. Commands that change object attributes involving clustering will update the object and send a request to the repository processor . Commands for working with clusters will be checked for syntax, and a request will be sent to the repository processor.
The requests sent to the repository processor are processed asynchronously, along with cluster requests received from other members of the cluster. In some cases, processing may take a considerable time if they have to be propagated around the whole cluster to determine if they are successful or not.

On z/OS

In both cases, message CSPARIS30I will be sent to the command issuer indicating that a request has been sent. This message is followed by message CSQ9022I to indicate that the command has completed successfully, in that a request has been sent. It does not indicate that the cluster request has been completed successfully.
Any errors are reported to the z/OS console on the system where the channel initiator is running, they are not sent to the command issuer.
This is not like channel operation commands, which operate synchronously, but in two stages.

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.

DEFTYPE	How the queue manager was defined. DEFTYPE can be one of the following: CLUSSDR Defined explicitly as a cluster-sender channel CLUSSDRA Defined by auto-definition as a cluster-sender channel CLUSSDRB Defined as a cluster-sender channel, both explicitly and by auto-definition CLUSRCVR Defined as a cluster-receiver channel
QMTYPE	Whether it holds a full repository or only a partial repository.
CLUSDATE	The date at which the definition became available to the local queue manager.
CLUSTIME	The time at which the definition became available to the local queue manager.
STATUS	The current status of the cluster-sender channel for this queue manager.
SUSPEND	Whether the queue manager is suspended.
CLUSTER	What clusters the queue manager is in.
CHANNEL	The cluster-receiver channel name for the queue manager.