Concurrency with other BMC AMI Recover executions

However, the following scenarios are not allowed in BMC AMI Recover:

• Submit two BMC AMI Recover jobs concurrently to recover all of the data sets of a space or the same data set of a space

• Recover a table space partition and unload keys from the same partition in two different concurrent jobs

  The utility issues a warning if you run more than one job that specifies RECOVER UNLOADKEYS for the same index and from the same partition or partitions of a table space.

Concurrency with RECOVER UNLOADKEYS and RECOVER BUILDINDEX

A special case of concurrency is one or more RECOVER UNLOADKEYS runs followed by a RECOVER BUILDINDEX run. Because these operations can be run in separate jobs, updates to the table space must be prevented between the completion of RECOVER UNLOADKEYS and the beginning of RECOVER BUILDINDEX to guarantee the integrity of the data.

For this reason, RECOVER UNLOADKEYS leaves the table space in RO (read only) status. BMC AMI Recover also adds a row to the BMCSYNC table for each partition from which keys have been unloaded; the utility ID is blank and SHRLEVEL is 'S'. This status prevents any other BMC AMI Recover run from recovering the table space before the row is removed by the RECOVER BUILDINDEX run.

In the same way, the RECOVER UNLOADKEYS run adds a row to the BMCSYNC table for each nonpartitioned index unloaded; the utility ID is blank and the BMCSYNC row is shared among all of the RECOVER UNLOADKEYS jobs for the same index. The RECOVER BUILDINDEX job deletes the BMCSYNC rows with blank utility IDs that were left by the corresponding RECOVER UNLOADKEYS jobs. The RECOVER BUILDINDEX job also checks the row for each index first to verify that all partitions have been unloaded, and issues a warning message if the row is not found. The job terminates with an error if it finds the row with indications that not all partitions have been unloaded.

For specific examples of concurrent BMC AMI Recover jobs, see Using multiple commands.