When you quiesce DFSMSrmm:
- DFSMSrmm completes requests that are being processed when the
quiesce is requested. Note that DFSMSrmm might fail the request if
manual recovery is to be performed or if there are I/O errors on the
control data set.
- Any requests accepted by DFSMSrmm are left on work queues until
DFSMSrmm recovery and refresh is completed.
- DFSMSrmm fails any new requests with an I/O error during manual
recovery or RMM not ACTIVE when DFSMSrmm is quiesced by command.
- In a multihost environment, conditions, which result in an automatic
quiesce of DFSMSrmm (such as control data set errors from which DFSMSrmm
cannot automatically recover), cause the quiesce on all hosts sharing
the control data set. Only after all hosts have successfully quiesced
can the control data set be recovered. Manually issuing a DFSMSrmm
quiesce affects only the host on which you issue the command. If
you want all hosts quiesced, you must issue the command on each host
that is sharing the control data set.
To quiesce DFSMSrmm, the operator should issue the command to quiesce
the subsystem, allow DFSMSrmm to deallocate the control data set and
the journal, and allow recovery processing to be performed.
Figure 1. Quiescing the DFSMSrmm subsystem interfaceMODIFY DFRMM,QUIESCE