Concurrency with other BMC utilities

All BMC utility products use the BMCUTIL table to control the use of utility IDs, identifiers of BMC utility runs.

The BMCUTIL table requires that each BMC utility product have a unique ID for restart purposes. For more information about this table, see BMCUTIL-table.

BMC utility products use the BMCSYNC table to coordinate access to Db2 objects. Db2 objects that participate in a BMC utility job are registered in the BMCSYNC table. When each object is registered, the registering utility assigns a share level to control access to that object from other BMC utilities. For partitioned Db2 spaces, registration is performed at the partition level. For more information about this table, see BMCSYNC-table.

When BMCSYNC is shared, BMC AMI Copy can coordinate access to spaces by jointly controlling space status with the other BMC utilities. The SHRLEVEL column in BMCSYNC is used to indicate to other utilities the level of sharing allowed by a utility. Coordinated access can be accomplished at the partition level for table spaces. The BMC AMI Copy utility can run concurrently with other BMC utilities that have a blank or an S in the SHRLEVEL column.

This use of the BMCSYNC table allows multiple BMC utilities or multiple instances of a single utility to operate concurrently on different partitions of the same Db2 space if no nonpartitioning indexes are involved. In addition, some BMC utilities can operate concurrently on the same object or partition.

For information about which products can operate concurrently, see the following table. For additional serialization and concurrency issues for each product, see the relevant product space.

The Access level column in the following table refers to the value of the SHRLEVEL column in the BMCSYNC table. The level can be one of the following values:

• S indicates shared access. Any other utility that registers with shared access (S) can run against the object.
• X indicates exclusive access. No other utility can run against the object.
• A blank value indicates that no status is requested and any other utility can run against the object.

Concurrency and Snapshot Copies

When the BMCSYNC table is shared, the mechanism varies according to whether BMC AMI Copy is making Snapshot Copies or not, as follows:

• When BMC AMI Copy is making non-Snapshot Copies, the first utility to access the target space records its status in BMCSYNC. Utilities might change the status as required by their SHRLEVEL requirements. The last utility to relinquish control of the space puts the space back to its initial status.

  You can also use the BMC AMI Copy installation option RESETCHG (see RESETCHG=YES) to indicate to BMC AMI Copy, when it is the last utility to relinquish control of a space while doing a SHRLEVEL CHANGE copy, whether to put the space back in its initial status or not.

• When BMC AMI Copy is making Snapshot Copies (that is, using SHRLEVEL CONCURRENT) and is the first utility to access the target space, the space is started in read-write (RW) status and BMC AMI Copy registers the original status as RW in the BMCSYNC table. If another utility is already running on the space, BMC AMI Copy leaves the space in its current status and continues to process the copy job. In both cases, the last utility to relinquish control of the space puts it back to its initial status.

Concurrency and the BMC AMI Copy MODIFY command

The BMC AMI Copy MODIFY command places an S in the SHRLEVEL column in the BMCSYNC table and can run concurrently with other BMC utilities that have a blank or an S in the SHRLEVEL column.

For the BMC AMI Copy MODIFY command, the UTILNAME in the BMCUTIL and BMCSYNC tables is COPY. NULL in the ORIG_STATUS column of the BMCSYNC table signals to other utilities that MODIFY is not participating in first-in/last-out START logic.

You cannot run concurrent BMC AMI Copy copy jobs and BMC AMI Copy MODIFY jobs against the same space, unless a copy is being made on behalf of a MODIFY VERIFY command request from the same UTILID.