Utility parameters on the EXEC statement
The following illustration shows the format of the EXEC statement:
// PARM='<ssid>,<utilID>,<restartParm>,msgLevel,checkPt,rdb2Stat,afrOpts'
The parameters ssid, utilID, and restartParm are positional and must be specified in the order shown.
You must specify the Db2 subsystem ID or group attach name for Db2 data sharing. However, if you do not specify the utility ID or the restart parameter and want to use the defaults for these parameters, you must include a comma as a placeholder for each parameter. For example, in a statement with the following format, the subsystem ID or group attach name (ssid) and the restart parameter (restartParm) are specified and the default is used for the utility ID:
After you specify the Db2 subsystem or group attach name, the utility ID, and the restart parameter, you can specify the remaining parameters in any order; they are non-positional. If you do not specify one of the non-positional parameters, BMC AMI Recover uses the default value for the utility parameter.
Db2 subsystem identifier (ssid)
The Db2 subsystem identifier is the one-character to four-character Db2 subsystem ID that identifies where the objects to be recovered reside. If the Db2 subsystem identifier is not coded in the runtime parameters on the JCL EXEC statement for the utility, the default value from the DSNHDECP module that is in the STEPLIB concatenation will be used. (The DSNHDECP module was created when Db2 was installed. The installation-generated DSNHDECP module typically resides in the SDSNEXIT library.)
You can also use the group attachment name (for Db2 data sharing) in place of the ssid parameter. Using the group attachment name, you can use the same JCL but run on any member of a data-sharing group. When a job is submitted with a group name, a subsystem in the group must be executing on the system where the job is submitted.
Utility Identifier (utilID)
This parameter specifies the ID that uniquely names a utility execution or job step. If you do not specify this parameter, BMC AMI Recover uses the default, userID.jobName.
The rules for utility ID are as follows:
- The utility ID can be 1 to 16 characters.
- The utility ID consists of alphanumeric characters, plus the following characters: #, $, @, !, ¬, . , and ¢.
When you run multiple BMC AMI Recover jobs concurrently, each job must use a unique utility ID.
Restart parameter (restartParm)
The restart parameter can have one of the values described in this topic.
The value that you choose for this parameter determines which of the following execution types is invoked:
- A new BMC AMI Recover execution
- An BMC AMI Recover execution that you want to restart
- A run to print control section information to track maintenance that has been applied without performing any other processing
For more information about resubmitting a failed BMC AMI Recover job, see Restarting-a-BMC-AMI-Recover-job.
Blank or not specified | This value is the default. If the utility ID is not present in the BMCUTIL table, this value starts a new BMC AMI Recover job. If the utility ID is already present in the BMCUTIL table, BMC AMI Recover terminates with an error. |
|---|---|
MAINT | MAINT limits processing to listing the installation options fixes applied to BMC AMI Recover, and the names of BMC tables. No recovery processing is performed. For examples, see MAINT. |
NEW | NEW starts a new BMC AMI Recover utility execution. You can reuse a utility ID that already exists in the BMCUTIL and BMCSYNC tables. (These tables are described in Common-utility-tables.) When you use NEW, any existing utility job with the same ID is replaced, and a new utility job is started. BMC AMI Recover will not allow the job to start if another job with the same utility ID on the same Db2 subsystem or data sharing group is active. For examples, see NEW. |
NEW/RESTART | If the utility ID already exists in the BMCUTIL table, NEW/RESTART restarts the utility job from the last recorded sync point or (if the last checkpoint taken was not for a sync point) from the beginning of the last incomplete phase. If the utility ID does not already exist, NEW/RESTART initiates a new BMC AMI Recover utility job. This option allows a job to be submitted again without changing the JCL in most cases. Some cases might require a change to DD statements with a disposition of NEW. For more information about sync points and checkpoints, see Restarting-a-BMC-AMI-Recover-job. For examples, see NEW/RESTART. |
NEW/RESTART(PHASE) | NEW/RESTART(PHASE) restarts the utility at the beginning of the last incomplete BMC AMI Recover phase if the utility ID already exists in the BMCUTIL table. Otherwise, NEW/RESTART(PHASE) starts the job as a new BMC AMI Recover utility job. This option allows a job to be submitted again without changing the JCL in most cases. Some cases might require a change to DD statements with a disposition of NEW. |
RESTART | If the utility ID already exists, RESTART restarts the utility from the last sync point or (if the last checkpoint taken was not for a sync point) from the beginning of the last incomplete phase. If the utility ID does not already exist in the BMCUTIL table, BMC AMI Recover terminates and issues an error message. For more information about sync points, see Restarting-a-BMC-AMI-Recover-job. |
RESTART(PHASE) | RESTART(PHASE) restarts the utility at the beginning of the last incomplete phase. A row for the utility ID must exist in the BMCUTIL table or the job terminates with an error message. |
TERM | Specifying TERM terminates a stopped or failed utility by removing all sync point and restart information for the utility ID from the BMCUTIL and BMCSYNC tables. You can use the TERM parameter to 'clean up' after an error condition; however, you might prefer to restart the recovery. BMC AMI Recover does not issue an error message when TERM is specified, and no row exists for the utility ID in the BMCUTIL table. |
Message level parameter (msgLevel)
This utility parameter determines which output files and messages BMC AMI Recover returns.
Valid values for MSGLEVEL are 0, 1, and 2. If you do not specifymsgLevel, BMC AMI Recover uses the default, MSGLEVEL(1). For a description of the output files that are returned by different values of MSGLEVEL, see the table in, BMC-AMI-Recover-data-sets-and-BMC-AMI-Recover-DD-statements. For samples of the different output files and their content, see Using-MSGLEVEL-to-control-BMC-AMI-Recover-output and for examples, see MSGLEVEL.
Checkpoint override parameter (checkPt)
This utility parameter overrides the CHECKPT installation option.
CHECKPT provides a means of controlling the overhead associated with taking checkpoints. Taking a checkpoint refers to the process of recording the end of a phase in the BMCUTIL and BMCSYNC tables. When a checkpoint is taken, message BMC40091 is issued. If you do not specify the checkpoint override parameter, the default is the value of the CHECKPT installation option.
For more information about CHECKPT, see Checkpoints-for-BMC-AMI-Recover-restart and BMC-AMI-Recover-installation-options.
The checkpoint override parameter can have a value of CHECKPT(NO) or CHECKPT(PHASE).
CHECKPT(NO) | CHECKPT(NO) causes no checkpoints to be taken, except those necessary to synchronize BMC AMI Recover execution with the execution of other BMC utilities and MERGE checkpoints that are necessary to guarantee the integrity of output copy, point-in-time recovery, or index rebuild registrations. CHECKPT(NO) is recommended for short BMC AMI Recover jobs in which you do not want to incur checkpoint overhead or that you do not mind rerunning entirely if necessary. |
|---|---|
CHECKPT(PHASE) | CHECKPT(PHASE) causes a checkpoint to be taken at the end of each processing phase if more than the number of minutes specified by the value of the CHECKINT installation option has passed since the last checkpoint was taken. For information about the CHECKINT installation option, see BMC-AMI-Recover-installation-options. Specify CHECKPT(PHASE) for longer running jobs when it would be costly to rerun the entire job. |
RDB2STAT override parameter (rdb2Stat)
This utility parameter overrides the RDB2STAT installation option.
RDB2STAT indicates the status to which Db2 objects should be returned at the successful completion of an BMC AMI Recover job. If you do not specify the RDB2STAT override parameter, BMC AMI Recover defaults to the setting of the RDB2STAT installation option. For information about the RDB2STAT installation option, see BMC-AMI-Recover-installation-options.
The RDB2STAT override parameter can have a value of RDB2STAT(YES), RDB2STAT(NO), RDB2STAT(RW), or RDB2STAT(RO).
RDB2STAT(YES) | RDB2STAT(YES) causes BMC AMI Recover to issue Db2 commands to restore the DB2 status of each space after BMC AMI Recover completes the requested operations. For examples of how BMC AMI Recover restores the initial status of a space, see Restoring initial status. For more information, see RDB2STAT-YES. |
|---|---|
RDB2STAT(NO) | RDB2STAT(NO) causes BMC AMI Recover not to issue Db2 commands to restore the DB2 status of spaces after an BMC AMI Recover run is complete. The spaces remain stopped. |
RDB2STAT(RW) | RDB2STAT(RW) causes BMC AMI Recover to issue Db2 commands to set the status of each space to read-write (RW) mode (regardless of the initial status of the space) after the requested operations have been completed successfully. |
RDB2STAT(RO) | RDB2STAT(RO) causes BMC AMI Recover to issue Db2 commands to set the status of each space to read-only (RO) mode (regardless of the initial status of the space) after the requested operations have been completed successfully. |
Installation options module parameter for BMC AMI Recover (afrOpts)
The installation options module parameter overrides the installation options module, AFR$OPTS, for BMC AMI Recover. Using this feature, you can provide a different options module at runtime. The length of the parameter determines how the parameter is used:
- If this parameter is greater than four characters in length, the options module specified by the parameter is loaded.
- If this parameter is less than or equal to four characters in length, the parameter is considered a suffix override for the OPTS part of the installation options module name. For example, specifying AFROPTS(TEMP) results in an attempt to load AFR$TEMP as the BMC AMI Recover options module.
As an alternative to afrOpts, you can also specify opts on the EXEC statement. For example, either of the following examples is valid:
PARM='DFC2,F312396B,NEW,MSGLEVEL(1),OPTS(AFR$DB2A)'
For information about the AFR$OPTS installation options module, see BMC-AMI-Recover-installation-options.