Since online processing is now competing with tape allocations and SWAPs for device group locks, it is possible for tape allocations and SWAPs on one system to delay online processing on another system and for online processing on one system to delay tape allocations and SWAPs on another system. For example, while a local job is in tape allocation and is holding the device group locks for a set of devices, VARY ONLINE commands issued on external systems for any of the devices for which the locks are held are delayed until the local job finishes the allocation process. Similarly, while online processing is occurring locally for a device, tape jobs on external systems that could possibly allocate the device (jobs that have the device in their Eligible Device List) are delayed until local online processing finishes for the device. In contrast, VARY OFFLINE commands do not require the device group locks to ensure serialization, and thus are not impacted by external processes that own the respective device group locks. However, because offline processing is now synchronized with online processing on the local system, it is possible that a VARY OFFLINE request is made to wait behind a VARY online request that is waiting for control of a device group lock that is actively held on an external system.
The CA MIA DIAGNOSE command can be used to diagnose delays in tape allocation, SWAP, and online processing. The DIAGNOSE command provides information about the device group lock usage by tape allocations, SWAP, and online processing for each system. Note that with CA MIA VARY device serialization, there is a limit of eight devices that request cross-system lock serialization for ONLINE processing at any given time. Therefore, the DIAGNOSE command reflects up to eight devices in cross-system lock processing. CA MIA can have devices queued for online processing that are not reflected in the DIAGNOSE command because there are already eight devices requesting cross-system lock serialization for online processing. Timeout logic has been implemented so that if a cross-system lock request for a device requiring online processing is not satisfied in 30 seconds, the request is re-queued, thus allowing other online requests on the queue to enter cross-system lock processing. This prevents an online request that is not able to obtain cross-system lock serialization in a timely manner from delaying, for extended periods, other waiting online requests that may be able to obtain their desired serialization.
| Copyright © 2011 CA. All rights reserved. | Tell Technical Publications how we can improve this information |