EXEC parameters for EDGHSKP

Figure 1 shows the EXEC parameters for EDGHSKP. DFSMSrmm uses all the parameters except CATSYNCH, DATE, and VERIFY if you do not specify PARM on the EXEC statement.

You can specify the EXEC parameters in any order, but DFSMSrmm processes them in this sequence:

CATSYNCH processing
VRSEL vital record processing
DSTORE storage location management processing
EXPROC expiration processing
RPTEXT extract data set creation
BACKUP control data set and journal back up processing

Figure 1. EDGHSKP EXEC parameters


>>-+-------------------------------------------+---------------><
   | .-,-------------------------------------. |   
   | V           .-AMS--.                    | |   
   '---+-BACKUP(-+-COPY-+-)----------------+-+-'   
       |         '-DSS--'                  |       
       +-RPTEXT----------------------------+       
       |           .-D-.                   |       
       +-DATEFORM(-+-A-+-)-----------------+       
       |           +-E-+                   |       
       |           +-I-+                   |       
       |           '-J-'                   |       
       '-+-| production_run_parameters |-+-'       
         '-| trial_run_parameters |------'         

production_run_parameters

   .-,-----------------------------------.   
   V                                     |   
|----+-CATSYNCH------------------------+-+----------------------|
     +-DSTORE(-| dstore_parameters |-)-+     
     +-EXPROC--------------------------+     
     '-VRSEL---------------------------'     

dstore_parameters

   .-,-------------------------------------------------------.   
   V                                                         |   
|----+-----------------------------------------------------+-+--|
     '-| location_parameters |-+------------+-+----------+-'     
                               '-INSEQUENCE-' '-REASSIGN-'       

location_parameters

                          .-:*-----------.     
|--LOCATION(from_location-+--------------+-)--------------------|
                          '-:to_location-'     

trial_run_parameters

          .-,VRSEL-.                                        
|--VERIFY-+--------+-+-----------+-+--------------------+-------|
                     '-,CATSYNCH-' '-,DATE(-+-date--+-)-'   
                                            '-+nnnn-'

The parameters on the EXEC statement are:

BACKUP(AMS | DSS | COPY)

Specify BACKUP to back up or copy the control data set, to back up the journal or to back up/copy both the control data set and the journal. When you specify BACKUP on the EXEC statement, you must also specify a DD statement. Specify BACKUP DD when you back up or copy the control data set and JRNLBKUP DD when you back up the journal. You can also specify both DD statements in your EDGHSKP JCL.

BACKUP(AMS) is the default. DFSMSrmm uses the access method services REPRO command to perform backup processing. Specify BACKUP(AMS) to prevent DFSMSrmm from updating the control data set during control data set backup processing. Backup cannot be directly to tape.

Specify BACKUP(DSS) to create a portable backup of the CDS. Use backup with the DFSMSdss concurrent copy environment set up to permit the update of the DFSMSrmm control data set during backup processing. This ensures that all tape activities can continue during backup processing. You can specify BACKUP(DSS) without setting up the concurrent copy environment, but CDS updates are prevented. If you specify BACKUP(DSS), backup can be direct to tape.

Specify BACKUP(COPY) to use DFSMSdss to create a copy of the CDS and optionally, a backup of the journal. The COPY uses DFSMSdss logical data set copy and enables you to use fast replication services that enables CDS updates to be made while the copy is created. COPY works just as the DSS option, but uses the COPY command instead of the DUMP command with DFSMSdss. The BACKUP DD is optional for COPY. Specify it if you want to direct the copy to a specific volume, or your environment is not SMS-managed.

For journal backup, DFSMSrmm uses IDCAMS to back up the journal even when BACKUP(DSS) is specified. When using EDGHSKP to perform back up, the journal can be cleared. Refer to Steps for automating control data set backup and journal clearing for information.

CATSYNCH

Specify CATSYNCH to update the DFSMSrmm control data set with information from available user catalogs. Synchronizing the DFSMSrmm control data set with the catalogs is normally a one-time setup action. See Running DFSMSrmm catalog synchronization for implementation details. Before you can synchronize the DFSMSrmm control data set with user catalogs, define system IDs by using the EDGRMMxx parmlib OPTION CATSYSID operand as described in Defining system options: OPTION.

Specify the EDGRMMxx parmlib OPTION CATSYSID(*) to indicate that catalogs are fully shared and that any data set can be processed by DFSMSrmm on any DFSMSrmm system. DFSMSrmm checks that the control data set has been synchronized prior to performing vital record processing or expiration processing. DFSMSrmm dynamically adds the CATSYNCH execution option when the control data set and catalogs are not synchronized and the EDGHSKP VRSEL or EXPROC parameters are specified.

If CATSYSID is specified with specific system IDs, you cannot run vital record processing until the control data set is synchronized with all user catalogs and you have run EDGUTIL with the SYSIN statement CONTROL CATSYNCH(YES). See Creating or updating the control data set control record for information about marking the control data set for synchronization.

Prior to synchronizing the DFSMSrmm control data set with available user catalogs, you can specify the VERIFY parameter with the CATSYNCH parameter to find differences between the DFSMSrmm control data set and the user catalogs. When you run CATSYNCH with VERIFY prior to implementation, you do not need to add the CATSYSID operand to parmlib. DFSMSrmm reports all the differences so you can make updates, if required, to catalog information before running CATSYNCH without the VERIFY parameter.

When you run the CATSYNCH parameter with the VERIFY parameter on a DFSMSrmm control data set that is already synchronized, and there are differences found between the catalog and the DFSMSrmm information, the differences are reported, but the DFSMSrmm control data set synchronization is unchanged. You should review the differences and make any changes to the catalogs as required and then use EDGUTIL UPDATE to mark the DFSMSrmm control data set as not synchronized. The next time you run the CATSYNCH parameter without the VERIFY parameter or when CATSYNCH is added automatically by EDGHSKP, the DFSMSrmm control data set and catalogs are synchronized again.

DFSMSrmm adds information about the data sets that are synchronized in the ACTIVITY report. It is expected that CATSYNCH is setup for unshared catalogs in a client server environment.

DATE(date|+nnnn)

Specify DATE to set the date used for VERIFY processing.

To specify a date with date, supply the year and day in one of two forms:

yyddd, where yy is the last two-digit number for the year and ddd is the three-digit number for the day of the year, such as 93001.
yyyy/ddd, where yyyy is the four-digit number for the year and ddd is the three-digit number for the day of the year, such as 1993/001. The slash is required.

For dates in the year 2000 and or in the 21st century or higher, you can only use the yyyy/ddd format. If you use the yyddd format, DFSMSrmm defaults to the 20th century.

To specify a number of days to add to the current date, supply +nnnn to determine the actual date to be used for VERIFY processing. You specify the value as a plus sign and the number of days, for example, to use the date in 7 days time specify DATE(+7).

The current date is the default.

DATEFORM (A|E|I|J|D)

Specify DATEFORM to set the date format for records that are written to the extract data set, records written to the ACTIVITY file, and any messages issued during inventory management.

Value	Language	Format	Example
A	American	mm/dd/yyyy	12/15/2013
E	European	dd/mm/yyyy	15/12/2013
I	ISO	yyyy/mm/dd	2013/12/15
J	Julian	yyyy/ddd	2013/349
D	Default	Installation's default in EDGRMMxx	Initially set to Julian

The default date format for all date fields is the value specified in the parmlib member EDGRMMxx. The value is initially set to J for Julian. To change the date format for each run of EDGHSKP, use the DATEFORM parameter.

DSTORE

Specify DSTORE for storage location management processing.

LOCATION(from_location:to_location, ...)

Specify this parameter if you want to perform storage location management processing by location.

Specify a pair of location names separated by a colon. You can specify 1 to 8 pairs of from_location:to_location names.

If you omit this parameter, DFSMSrmm performs storage location management processing for all volumes that are required to move.

The from_location is the name of the location from which the volume should move. The to_location is the name of the destination for the volume.

These location names can be specified in one of these ways:

Specify a specific location using 1 to 8 character names.
Specify all locations using a single asterisk (*).
Specify all locations that begin or end with specific characters, such as ATL* or *DR.
Use the percent sign % in the location name to replace a single character. You can specify up to eight % in a location name mask.

DFSMSrmm does not validate the location names that you specify against the DFSMSrmm LOCDEF entries or the names of SMS libraries.

INSEQUENCE

Specify INSEQUENCE for volumes that are required to move from a non-bin-managed location to a bin-managed location.

Storage location management processing assigns volumes to available bins in volume sequence and bin sequence, starting with the lowest volume serial number and the lowest bin number.

All bins that become available in a single run of storage location management processing can be reused for other volumes. Bins can become available during storage location management processing under these conditions:

Global confirm move processing.
Volumes starting a move out of the bin with parmlib option REUSEBIN(STARTMOVE) specified.

If REASSIGN is also specified, the volumes that restart their move are merged in sequence with those volumes that have just started their move. Freed bins are merged with empty bins.

Bins are best utilized, if INSEQUENCE and REASSIGN are specified and parmlib option REUSEBIN(STARTMOVE) is also specified. Fewer empty bins need to be defined.

When you do not specify INSEQUENCE, the DFSMSrmm DSTORE processing assigns volumes to bins in the sequence that volumes are processed. Each time a volume is assigned to a bin, the lowest empty bin number is used. The exact bin depends on the setting of the REUSEBIN option.

REASSIGN

Specify REASSIGN for volumes that are already moving from a storage location that is not bin-managed storage location and the required location is either a bin-managed storage location or is different from the destination. When you specify REASSIGN, you are canceling the move for these volumes and requesting that the move for the volumes is restarted so that DFSMSrmm could assign these volumes to other locations or bins.

If the LOCATION parameter is specified, DFSMSrmm reassigns a volume when at least one of the LOCATION subparameter pairs matches the volume's current location name and destination name.

EXPROC

Specify EXPROC for expiration processing. When you specify the EXPROC execution parameter, you can also optionally specify the EXPROC command in SYSIN to tailor expiration processing. See SYSIN file for the EDGHSKP utility for details.

RPTEXT

Specify RPTEXT to create an extract data set. When you specify RPTEXT as the only execution parameter you enable DFSMSrmm to create your extract at the same time that other RPTEXT or inventory management requests are being processed. When there are multiple requests, you must provide a MESSAGE file and a REPTEXT file or an XREPTEXT file for each extract request.

VERIFY

Specify VERIFY to request that DFSMSrmm performs a trial run of selected processing. You can run a trial run for vital record processing and catalog synchronization. When you specify VERIFY, DFSMSrmm performs the requested processing, but does not update the DFSMSrmm control data set as a result of the processing.

You could specify VERIFY to perform a trial run to test new vital record specifications that you define to DFSMSrmm. Run VERIFY to confirm that your new and changed retention and movement policies achieve the expected results. If all you want to perform is a trial run of vital record processing, you can specify VERIFY with or without the VRSEL parameter. You can use the DATE parameter with VERIFY to set a date to perform VERIFY processing. When you specify VERIFY, you can use all the inventory management parameters except DSTORE and EXPROC. The ACTIVITY file is required when you select the VERIFY option.

The DFSMSrmm parmlib OPTION VRSCHANGE operand default of VERIFY prevents inventory management vital record processing when there are policy changes that have not been tested. You only need one successful run of VERIFY before you can continue with inventory management processing. If VERIFY completes successfully, but you do not obtain the vital record specification results you expected, you must continue to modify policies and run VERIFY until you obtain acceptable results.

VRSEL

Specify this parameter for vital record processing. To perform a trial run of vital record processing, you can also specify the VERIFY parameter and optionally the DATE parameter. Performing a trial run allows you to see how DFSMSrmm vital record processing changes affect data set and volume information before the control data set is updated.