SUSPEND QMGR
Use the MQSC command SUSPEND QMGR to advise other queue managers in a cluster to avoid sending messages to the local queue manager if possible, or to suspend logging and update activity for the queue manager until a subsequent RESUME QMGR command is issued. Its action can be reversed by the RESUME QMGR command. This command does not mean that the queue manager is disabled.
UNIX and Linux® | Windows |
---|---|
Usage notes
On z/OS:- If you define CLUSTER or CLUSNL, be aware of the following behavior:
- The command fails if the channel initiator has not been started.
- Any errors are reported to the system console where the channel initiator is running; they are not reported to the system that issued the command.
- The SUSPEND QMGR and RESUME QMGR commands are supported through the console only. However, all the other SUSPEND and RESUME commands are supported through the console and command server.
Parameter descriptions for SUSPEND QMGR
The SUSPEND QMGR with the CLUSTER or CLUSNL parameters to specify the cluster or clusters for which availability is suspended, how the suspension takes effect and, on z/OS, controls logging and update activity and how the command is executed when the queue manager is a member of a queue-sharing group.You can use the SUSPEND QMGR FACILITY(DB2) to terminate the queue manager connection to Db2. This command might be useful if you want to apply service to Db2. Be aware, if you use this option then there is no access to Db2 resources, for example, large messages which might be offloaded to Db2 from a coupling facility.
You can use the SUSPEND QMGR FACILITY(IMSBRIDGE) to stop sending messages from the WebSphere MQ IMS bridge to IMS OTMA.
- CLUSTER(clustername)
- The name of the cluster for which availability is to be suspended.
- CLUSNL(nlname)
- The name of the namelist that specifies a list of clusters for which availability is to be suspended.
- LOG
- Suspends logging and update activity for the queue manager until
a subsequent RESUME request is issued. Any unwritten log buffers are
externalized, a system checkpoint is taken (non-data sharing environment
only), and the BSDS is updated with the high-written RBA before the
update activity is suspended. A highlighted message (CSQJ372I) is
issued and remains on the system console until update activity has
been resumed. Valid on z/OS only. If LOG is specified,
the command can be issued only from the z/OS system console.
This option is not permitted when a system quiesce is active by either the ARCHIVE LOG or STOP QMGR command.
Update activity remains suspended until a RESUME QMGR LOG or STOP QMGR command is issued.
This command must not be used during periods of high activity, or for long periods of time. Suspending update activity can cause timing-related events such as lock timeouts or WebSphere MQ diagnostic memory dumps when delays are detected.
- CMDSCOPE
- This parameter applies to z/OS only and specifies how the command is executed when the queue manager
is a member of a queue-sharing group.
- ' '
- The command is executed on the queue manager on which it was entered. This is the default value.
- qmgr-name
- The command is executed on the queue manager you specify, providing
the queue manager is active within the queue-sharing group.
You can specify a queue manager name, other than the queue manager on which the command was entered, only if you are using a queue-sharing group environment and if the command server is enabled.
- MODE
- Specifies how the suspension of availability is to take effect:
- QUIESCE
- Other queue managers in the cluster are advised to avoid sending messages to the local queue manager if possible. It does not mean that the queue manager is disabled.
- FORCE
- All inbound channels from other queue managers in the cluster are stopped forcibly. This occurs only if the queue manager has also been forcibly suspended from all other clusters to which the channel belongs.
The MODE keyword is permitted only with CLUSTER or CLUSNL. It is not permitted with the LOG or FACILITY parameter.