The other main structures found in CA MIM control files are CA MIM transactions. There are over 28 different CA MIM transactions that represent changes to managed resources. Each CA MIM component has transactions unique to that component. The following table illustrates some of the transaction types associated with each CA MIM component:
|
Component |
Transaction Types |
|---|---|
|
CA MIM |
GLOBALVALUE changes |
|
CA MIA |
Tape device status changes, preferencing |
|
CA MII |
Enqueues, dequeues, conflicts, job requeue |
The size of a particular CA MIM transaction is variable in length. For example, the size of a CA MIC cross-system message transaction is dependent on the length of the message text. Likewise, the size of a CA MII enqueue transaction is dependent on the resource name length (RNAME): the longer the data set name, the longer the CA MII transaction. In its simplest form, an individual CA MIM transaction is mapped something like this:
|
Transaction Map |
|
Size |
|
Type |
|
Flags |
|
Routing Mask |
|
Transaction-specific |
The routing mask field is used to direct the transaction to specific systems. For example, if a user on SYSA is granted access to a particular data set, then CA MII on SYSB and SYSC needs to be informed of this fact. In this case, CA MII on SYSA creates a transaction having a routing mask for SYSB and SYSC, and writes the transaction to the CA MIM control file. Once CA MIM on SYSB and SYSC have read and processed this transaction, it is deleted from the control file. Remember that CA MIM transactions are in the control file for a brief period of time-ideally for less than one second. The more often each CA MIM address space accesses the control file, the faster CA MIM transactions are processed and deleted from the control file, so the complex-wide throughput time will be better.
| Copyright © 2011 CA. All rights reserved. | Tell Technical Publications how we can improve this information |