|
|
|
The term control file cycle refers to the process of an individual CA MIM address space obtaining serialization to the control file, reading, processing, and writing data to and from the control file, and then finally releasing the control file. A single control file cycle is all that is required by a CA MIM address space to update its “picture” of all outstanding resources in the MIMplex. The star topology has been employed by CA MIM for over 20 years and is currently used with both the physical and virtual control file architectures.
The internal CA MIM processes involved in every control file cycle is illustrated here:
RESERVE the control file
Read and copy the first block (GMR) into local storage
Check the state of the MIMplex by interrogating the GMR
Read and direct incoming transactions to each component driver (MIA, MII, MIC)
Receive outbound transactions from each component driver
Update the GMR residing in private storage
Write new GMR and transactions out to the control file
RELEASE the control file
The duration of a single control file cycle depends on a number of factors. The more transactions there are to process, the longer the duration of a control file cycle. The volume of transactions is governed by the amount of resource activity on a system combined with whether CA MIM is managing those resources. CA MIM parameters tell CA MIM what type of resources it should be managing. The more resources you tell CA MIM to manage, the more CA MIM transactions that are generated, and the longer each control file cycle.
One way to optimize CA MIM is to ensure your CA MIM parameters involving transaction processing are defined correctly. There are a number of CA MIM parameter definitions that may cause unnecessary CA MIM transactions to be created, or may cause unnecessary CA MIM address space overhead, which elongates the control file cycle times.
You can also expect elongated CA MIM control file cycle times on systems that are CPU constrained, real storage constrained, or I/O bound.
Another aspect of control file cycle processing that affects the cycle completion time is that the frequency of control file cycles is different on every system in the MIMplex. Control file cycles are driven by either of two events:
CA MIM on a system with a large amount of managed enqueue requests will access the control file more frequently than CA MIM on a system that has very little managed enqueue requests. If you have a MIMplex comprised of systems running a range of heavy to light enqueue workloads, then CA MIM address spaces on those systems will be accessing the control file at different frequencies. In other words, CA MIM on a production system may perform control file cycles at a rate of 25 times per second, while CA MIM on a test system may perform a control file cycle only one time per second. Severely disproportionate control file access rates by CA MIM on different systems will elongate individual control file cycle times and, in turn, degrade CA MIM transaction processing times.
| Copyright © 2011 CA. All rights reserved. | Tell Technical Publications how we can improve this information |