During an HCD ACTIVATE, the IOS address space holds a shared enqueue on SYSIEFSD/DDRTPUR. As discussed in prior sections, z/OS DDR processing uses an exclusive enqueue on SYSIEFSD/DDRTPUR to serialize SWAP allocations with allocations, other SWAPs, and HCD ACTIVATE. Therefore, when an ACTIVATE is occurring on a system, SWAPs on that system are delayed until the ACTIVATE completes and releases the SYSIEFSD/DDRTPUR enqueue. Conversely, when a SWAP is occurring, ACTIVATEs are delayed on that system until SWAP processing releases the SYSIEFSD/DDRTPUR enqueue.
If a SWAP starts and requests the SYSIEFSD/DDRTPUR exclusive enqueue while an ACTIVATE in progress holds the enqueue shared, then the SWAP waits behind the ACTIVATE due to the exclusive SYSIEFSD/DDRTPUR enqueue. Also, any new allocations and SWAPs on the local system wait behind the exclusive enqueue for the SWAP. In this situation, all local SWAPs and allocations are delayed until the ACTIVATE completes.
CA MIA serializes SWAPs by requesting the device group locks for the devices indicated on DDR unit allocation calls during the SWAP. Since CA MIA uses locks rather than an exclusive SYSIEFSD/DDRTPUR enqueue to serialize the SWAPs on external systems in the MIMplex, only allocations and SWAPs needing the same device group locks are delayed on the external systems. No other allocations and SWAPs are delayed and HCD ACTIVATEs are not delayed on the external systems. Also, because CA MIA does not need to obtain a blocking SYSIEFSD/DDRTPUR enqueue on the external systems, HCD ACTIVATEs on external systems will not delay a SWAP occurring locally. A local SWAP is delayed only by allocations or SWAPs on external systems that need the same device group lock as the local SWAP. The CA MIA device lock serialization provides a very granular level of cross-system SWAP serialization.
| Copyright © 2012 CA. All rights reserved. | Tell Technical Publications how we can improve this information |