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


Managing catalogs in an RMMplex

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

You can implement DFSMSrmm client/server support with or without sharing catalogs across all of the systems in the RMMplex. You must, however, identify to DFSMSrmm whether catalogs are shared or not using the EDGRMMxx parmlib OPTION CATSYSID command described in OPTION command operands in the parmlib member for each system.

DFSMSrmm uncatalogs data sets on a volume, when you specify the EDGRMMxx parmlib OPTION UNCATALOG command under these conditions:
  • The commands must be processed on the system the data set was created on if all the catalogs are not shared.
  • A volume is returned to scratch status, DFSMSrmm uncatalogs all the data sets on the volume.
  • The RMM DELETEVOLUME FORCE subcommand is issued for a volume, DFSMSrmm uncatalogs all the data sets on the volume.
  • The RMM CHANGEVOLUME DSNAME subcommand is issued for a volume, DFSMSrmm uncatalogs all the data sets on the volume. If the data set name specified on the RMM CHANGEVOLUME subcommand matches the data set name on the volume, then DFSMSrmm only uncatalogs subsequent data sets.
  • The RMM DELETEDATASET subcommand is issued for a data set, DFSMSrmm uncatalogs the data set. Also, DFSMSrmm uncatalogs all data sets recorded on the same volume with higher data set sequence numbers.
  • A tape data set is overwritten, DFSMSrmm uncatalogs the data set. Also, all data sets recorded on the same volume with higher data set sequence numbers are uncataloged.
  • When the volume on which data sets resides is returned to scratch status, DFSMSrmm uncatalogs data sets.
  • Confirming the erasure or initialization of a volume
  • Returning volumes to scratch status, and DFSMSrmm performs the return to scratch cleanup actions

To use the DFSMSrmm catalog processing, you must synchronize the catalogs with the DFSMSrmm control data set. The catalog status for all data sets is maintained in the server system control data set. With unshared catalogs, the UNCATALOG parmlib option, on the server system, cannot be honored for data sets created on the client systems because the server cannot communicate with the client to initiate uncatalog processing. However, when processing is requested from the client, there is special recognition and handling of the request so that any catalog or RACF profile updates can be initiated on the client system. To synchronize the control data set and the catalogs, specify the EDGRMMxx parmlib OPTION CATSYSID(list_of_sysids). See Running DFSMSrmm catalog synchronization for additional information. Then run EDGHSKP with CATSYNCH, VERIFY, and EXPROC on the client system.

For example, you have 3 systems; SystemA is to run as a client and has no shared DASD in common with SystemB. SystemC will run in a sysplex and share their own catalogs and the DFSMSrmm control data set.
  • For client SystemA, specify the EDGRMMxx parmlib OPTION CATSYSID(SystemA) SYSID(SystemA) ..... CLIENT(....) command
  • For SystemB, specify the EDGRMMxx parmlib OPTION CATSYSID(SystemB,SystemC) SYSID(SystemB) .... SERVER(....) command
  • For SystemC, specify the EDGRMMxx parmlib OPTION CATSYSID(SystemB,SystemC) SYSID(SystemC) .... command

Run EDGHSKP CATSYNCH once on the client system SystemA, once on one of the systems SystemB or SystemC, and then run EDGUTIL with PARM=UPDATE and SYSIN containing the statement; CONTROL CATSYNCH(YES).

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014