Using multiple commands
BMC AMI Recover does not support commands in the input data set that execute other utilities.
General restrictions for multiple commands
The following general restrictions apply when you use multiple command statements:
No space may be named or implied for recovery in an BMC AMI Recover job more than once. For the purposes of this restriction, the data sets of a table space are considered separate objects. For example, the following command statements would be incorrect if AFRIND1 was an index on a table in table space AFRDB.AFRTS:
REBUILD INDEX (AFRIND1) REBUILD INDEX(ALL) TABLESPACE AFRDB.AFRTS
However, the following command statements are correct:
REBUILD INDEX (AFRIND1) PART 1 REBUILD INDEX (AFRIND1) PART 2 REBUILD INDEX (AFRIND2)
If RECOVER UNLOADKEYS command statements are present for any partition of a table space, REBUILD INDEX command statements on nonpartitioned indexes for the same table space are not valid. However, REBUILD INDEX command statements for the partitioned index on the space are valid.
For example, the following command statements are incorrect if AFRIND2 is a nonpartitioned index:
REBUILD INDEX (AFRIND2) TABLESPACE AFRDB.AFRTS RECOVER UNLOADKEYS (AFRIND3) PART 1 TABLESPACE AFRDB.AFRTS
Because the first command statement requires that all partitions of the table space be read to extract keys for the nonpartitioned index, you should perform one of the following actions:
Unload keys for both indexes in one or more jobs and follow these jobs with a RECOVER BUILDINDEX job
Recover both indexes in one job by using REBUILD INDEX
The following command statements are correct:
REBUILD INDEX (AFRIND1) PART 1 RECOVER UNLOADKEYS (AFRIND2, AFRIND3) PART 1
This execution rebuilds the partitioned index while extracting the keys for nonpartitioned indexes from partition 1 of the space. BMC AMI Recover processes these two command statements concurrently.
RECOVER BUILDINDEX, when present, must be the only command in the job step.
The ANALYZE option may be on any command statement and overrides the default (ANALYZE YES). If you specify the option on more than one BMC AMI Recover command statement, the value (YES, NO, or ONLY) must be the same in all cases.
When you are recovering a cloned object, all related objects named in the job must also be clones. For example, the following command statements are incorrect:
RECOVER TABLESPACE AFRDB.AFRTS CLONE RECOVER INDEX(ALL) TABLESPACE AFRDB.AFRTS
Restrictions for STOGROUP-defined objects
When you want to recover multiple STOGROUP-defined objects with some objects reallocated and others not reallocated (by using the REDEFINE option), you must use one command statement to reallocate objects and a second command statement for those objects that are not reallocated, as follows:
For table space recovery, use one RECOVER TABLESPACE command statement for table spaces that are reallocated and a second RECOVER TABLESPACE command statement for table spaces that are not reallocated. For more information, see REDEFINE for IMPORT.
To rebuild an index space by using REBUILD INDEX, use one command statement for index spaces that are reallocated and a second command statement for index spaces that are not reallocated. For more information, see REDEFINE for REBUILD INDEX.
For index space recovery by using RECOVER BUILDINDEX, use one command statement for index spaces that are reallocated and a second command statement (in a separate execution) for index spaces that are not reallocated. For more information, see REDEFINE for RECOVER BUILDINDEX.
General information about SORTDEVT and SORTNUM
You can specify SORTDEVT and SORTNUM in the installation options, or with the following BMC AMI Recover commands:
RECOVER TABLESPACE, RECOVER INDEXSPACE, or RECOVER INDEX
SORTDEVT and SORTNUM values override other values as follows:
Values on the preceding RECOVER commands or the REBUILD INDEX command override the values on the OPTIONS command
Values on the OPTIONS command override the values in the installation options module
If you specify SORTNUM with the OPTIONS, RECOVER, or REBUILD commands, and you do not specify SORTDEVT with any of the commands or you define SORTDEVT in the installation options module, BMC AMI Recover ignores SORTNUM.
Restrictions for key work data sets, SKEYDDN, SORTNUM, and SORTDEVT
You may have multiple REBUILD INDEX command statements, RECOVER UNLOADKEYS command statements, or both. Restrictions on the key work data sets and the SORTNUM and SORTDEVT options of these statements are designed to allow the most efficient processing of all command statements. The restrictions are determined by whether the table space for the indexes is partitioned or nonpartitioned and, if partitioned, whether nonpartitioned indexes are being rebuilt or whether RECOVER UNLOADKEYS is specified.
Restriction for nonpartitioned table space recoveries
You do not need to specify multiple REBUILD INDEX command statements for one nonpartitioned table space, but with BMC AMI Recover you can specify multiple statements. However, because BMC AMI Recover unloads the keys concurrently for all of the indexes, the key work data sets and the SORTDEVT and SORTNUM options must be the same on all statements for one table space.
Restrictions for partitioned table spaces
Restrictions for partitioned table spaces vary according to whether you are rebuilding a partitioned or nonpartitioned index and whether you specify RECOVER UNLOADKEYS.
Partitioned index rebuild
If you specify only partitioned index recovery, no restrictions exist on the key work data sets or the SORTNUM and SORTDEVT options. The following examples are allowed:
REBUILD INDEX (AFRIND1) PART 1 WORKDDN KEYS REBUILD INDEX (AFRIND1) PART 2 NOWORKDDN REBUILD INDEX (AFRIND1) PART 1 WORKDDN KEYS REBUILD INDEX (AFRIND1) PART 2 WORKDDN KEYS
You can use WORKDDN only with MAXKSORT 1.
Nonpartitioned index rebuild
When you specify REBUILD INDEX for a nonpartitioned index, the key work data sets and the SORTDEVT and SORTNUM options must agree on all REBUILD INDEX command statements for the table space, including those for all of a partitioned index or parts of a partitioned index. This agreement allows BMC AMI Recover to extract keys for all indexes from each partition during one pass of the table space.
RECOVER UNLOADKEYS specified
When you specify RECOVER UNLOADKEYS, a data set is created to hold the keys for a subsequent job that builds the index. The keys for all partitions of a table space within the step are required to be in one data set that is designated by the SKEYDDN ddname. Generally, if you run RECOVER UNLOADKEYS jobs for every table space partition, you can code one of the following command statements (in each job):
RECOVER UNLOADKEYS(ALL) TABLESPACE...PART nn RECOVER UNLOADKEYS (indexName1,...indexNamen)PART nn
If you specify multiple RECOVER UNLOADKEYS command statements for the table space, you must use the same SKEYDDN option on these command statements. If other REBUILD INDEX or RECOVER UNLOADKEYS command statements reference other table spaces or other partitions, the keys for different table spaces must be unloaded to different data sets. Name these data sets with the SKEYDDN option.
For example, you could code the following command statements:
RECOVER TABLESPACE AFRDB.AFRTS1 DSNUM 1 TABLESPACE AFRDB.AFRTS2 DSNUM 1 RECOVER UNLOADKEYS (ALL) TABLESPACE AFRDB.AFRTS1 PART 1 REBUILD INDEX (AFRIND1) TABLESPACE AFRDB.AFRTS1 PART 1 RECOVER UNLOADKEYS (ALL) TABLESPACE AFRDB.AFRTS2 PART 1 SKEYDDN TS2K REBUILD INDEX (AFRCLUS) TABLESPACE AFRDB.AFRTS2 PART 1
The keys for the nonpartitioned indexes of AFRDB.AFRTS1 are directed to the default DDNAME SKEY. The keys for the nonpartitioned indexes of AFRDB.AFRTS2 are directed to the DDNAME TS2K. SKEY and TS2K are ddnames, not prefixes. The keys for the partitioned indexes AFRIND1 and AFRCLUS are directed to NOWORKDDN by default.