z/OS DFSMSrmm Implementation and Customization Guide
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Quiescing DFSMSrmm

z/OS DFSMSrmm Implementation and Customization Guide
SC23-6874-00

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 interface
MODIFY DFRMM,QUIESCE

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014