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


Synchronizing the DFSMSrmm control data set with user catalogs when catalogs are not fully shared

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

When catalogs are not fully shared, you can have non-GDG and GDG data sets with the same name that are cataloged but in different, unshared catalogs. To retain all copies of all data sets, define a retention policy that uses DAYS with COUNT(99999) rather than CYCLES. Using CYCLES can produce unpredictable results for example, the premature expiration of data sets.

To ensure cycles are grouped together, use the jobname to further qualify the data sets, using a different jobname for each set of cataloged data sets. For example, use JOBNAME(xjzA) for data sets created on system A, and JOBNAME(xjzB) for data sets created on system B so that the cycle retention is based on the scope of the creation system.

The DFSMSrmm control data set and user catalogs must be synchronized for DFSMSrmm to support unshared user catalogs. To synchronize the DFSMSrmm control data set with user catalogs, follow these procedures:

  1. Ensure that all systems that share the control data set are running the DFSMSrmm level of code that supports catalog tracking and catalog synchronization. When you have the correct level of DFSMSrmm code installed, DFSMSrmm dynamically records all catalog updates for tape data sets in the control data set.
  2. Run the DFSMSrmm EDGHSKP utility with the PARM=CATSYNCH,VERIFY parameter as a trial run to find all the differences between the DFSMSrmm control data set and the catalogs and to ensure that the catalogs can be used successfully. Before you run CATSYNCH, you should verify that your MESSAGE data set is large enough to contain all the messages issued during the verify processing. For example, when you run CATSYNCH for the first time, perhaps as part of DFSMSrmm implementation, or when you run CATSYNCH with VERIFY, you should expect messages for each data set where the status is different between the catalogs and the DFSMSrmm control data set.
  3. Specify the DFSMSrmm EDGRMMxx parmlib OPTION CATSYSID operand with the system IDs that are common to the set of user catalogs on the system. Specify current IDs and previously used IDs if you are still retaining data sets from those systems.
  4. Set up automatic synchronization by automating the responses to DFSMSrmm messages EDG8200E and EDG8201E running the EDGUTIL UPDATE with the SYSIN command CONTROL CATSYNCH(NO).
  5. Run the DFSMSrmm EDGHSKP utility with the PARM=CATSYNCH parameter to partially synchronize all data set records in the control data set with the status from the accessible catalogs. Run CATSYNCH on other systems that share the control data set until all the catalogs have been synchronized. Before you run CATSYNCH you should verify that your MESSAGE data set is large enough to contain all the messages issued during the catalog synchronization process. For example, when you run CATSYNCH for the first time, perhaps as part of DFSMSrmm implementation, or you run CATSYNCH with VERIFY you should expect messages for each data set that must be updated or the status is different between the catalogs and the DFSMSrmm control data set.
  6. Run EDGUTIL with PARM=UPDATE parameter and CONTROL CATSYNCH(YES) to set the 'last catalog synchronization date and time' in the DFSMSrmm control data set control record.
  7. Run inventory management functions on any one system at any time. However, if you run expiration processing to return volumes to scratch status, DFSMSrmm only processes a subset of volumes.
  8. You must run EDGHSKP expiration processing on multiple systems if you specify the EDGRMMxx parmlib OPTION UNCATALOG(Y or S). You should run expiration processing once for each set of user catalogs on a system with access to those user catalogs.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014