Concurrency with other BMC utilities
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, 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 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 more 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.
Product | Access level | More information |
---|---|---|
CHECK PLUS | S | None |
S or blank |
| |
DASD MANAGER PLUS(BMCSTATS) | S | None |
LOADPLUS | X | If you specify PART, LOADPLUS registers only the specified partitions with exclusive access (X). If no nonpartitioned indexes exist on the table space, you can run other utilities on different partitions concurrently with this job. |
X, S, or blank |
| |
S | None | |
REORG PLUS | X | If you specify PART, REORG PLUS registers only the specified partitions with exclusive access (X). If no nonpartitioned indexes exist on the table space, you can run other utilities on different partitions concurrently with this job. |
UNLOAD PLUS | S | None |
Concurrency and Snapshot Copies
When the BMCSYNC table is shared, the mechanism varies according to whether
is making Snapshot Copies or not, as follows:
When
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
installation option RESETCHG (see RESETCHG=YES) to indicate to
, 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
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
registers the original status as RW in the BMCSYNC table. If another utility is already running on the space,
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
MODIFY command
The
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
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
copy jobs and
MODIFY jobs against the same space, unless a copy is being made on behalf of a MODIFY VERIFY command request from the same UTILID.