|
|
|
During initialization, CA MIA issues an exclusive enqueue with a QNAME of GTALOCAL and an RNAME of UP. It holds this resource for the entire duration that the address space is active. This enqueue resource prevents multiple versions of CA MIA from running concurrently on the same system. If the enqueue resource cannot be obtained during initialization processing, the CA MIA address space terminates.
The GTALOCAL enqueue resource is also used as a form of resource management by some of the CA MIA system intercepts. Specifically, those system intercepts that execute in a user's address space, and that make a request of the CA MIA address space and wait for a response, make use of a GTALOCAL enqueue resource during the time they are suspended. The intercept issues a shared request for an enqueue resource that is always held exclusively by the CA MIA address space. The intercept waits for a response to its request from the CA MIA address space or for shared control of the GTALOCAL enqueue resource. Should some event terminate the CA MIA address space that prevents normal post-back and clean-up processing, such as an operator FORCE command, the intercepts are redispatched from their wait condition and discover that they have received control for the GTALOCAL enqueue resource. This prevents the intercepts from remaining in an enabled wait, and permits them to continue processing with the knowledge that the CA MIA address space has terminated.
The GTALOCAL enqueue resource RNAME is used to identify the process involved in the intercept wait condition. The current RNAMEs in use are:
Normally, the amount of time an intercept waits for a request to be serviced by the CA MIA address space is minimal, thus the resource management enqueue conflict between the intercept executing in a user's address space and the CA MIA address space rarely surface. However, there are circumstances that can cause the resource management GTALOCAL enqueue conflict to become visible. For example, a job in allocation recovery processing holds device group locks during the time that the MIM2060 (or IEF238D) WTOR is outstanding. The CA MIA address spaces on all systems maintain global knowledge of the device group locks. Should any job on an external system request any of the device group locks held by the job in allocation recovery, the requesting job is required to wait until such time that the desired device group locks are available. While any job requesting device group locks is waiting for a response to continue from the CA MIA address space, that job remains in enqueue conflict. The conflict shows the CA MIA address space having exclusive ownership of the enqueue resource QNAME, GTALOCAL, and RNAME, Waiting_For_Device_Group_Locks while jobs waiting for shared ownership of the named enqueue resource are, in reality, waiting for the CA MIA address space to grant them control of the requested device group locks. Once the allocation recovery event is satisfied and ownership of the device group locks can be granted by the CA MIA address space, the waiting jobs are re-dispatched and will drop their request for the resource management enqueue, thus, eliminating the enqueue resource conflict.
CA MIA also makes use of enqueue resources to control intersecting processes between intercepts in a user's address space and the CA MIA address space. Again, the GTALOCAL enqueue resource RNAME is used to identify the process involved in the intercept wait condition.
| Copyright © 2011 CA. All rights reserved. | Tell Technical Publications how we can improve this information |