An affinity is a relationship that you define between two or more transactions and the duration (or lifetime) of that relationship. When an affinity relationship exists between transactions, those transactions must be processed by the same target region. You can use affinities to route transactions from one or more requesting regions to a specific target region based on the rules applying to a particular combination of an affinity relation and lifetime. For a list of affinity relation and lifetime values, see Valid affinity relation and lifetime combinations and their meanings.
When multiple CMASs in the CICSplex manage affinities for
the workload, and one of these CMASs is brought down and the local MASs stay
up, the workload becomes frozen. When the workload is frozen, it cannot be
changed, however the current workload remains active.
When a CMAS is down, and you have any of the following affinity
life times and affinity relationships, a new affinity instance cannot be
created, and the transaction cannot be routed to the target MAS associated
to the to the affinity, because the local TORs cannot be informed of the workload
changes while the workload is frozen.
Affinity relation | Affinity Lifetime |
---|---|
USERID |
|
LUNAME |
|
GLOBAL |
|
BAPPL |
|
When the CMAS is brought back up and reconnects to the MASs,
the workload is un-frozen and is able to be changed.
You can use the IBM® CICS Interdependency Analyzer for z/OS® to detect existing affinities between
transactions and between BTS processes and activities. The
output from the Reporter component of that utility can be used as input to the CICSPlex® SM batched repository-update facility.
For more information, see the CICS Interdependency Analyzer for z/OS User's Guide and Reference.
Although BTS itself does not introduce any affinities, and discourages programming techniques that do, it does support existing code that may introduce affinities. You must define such affinities to workload management. It is particularly important to specify each affinity’s lifetime. Failure to do this may restrict unnecessarily the workload management routing options.
It is important to note that a given activity can be run both synchronously and asynchronously. Workload management is only able to honour invocations that are made asynchronously. Furthermore, you are strongly encouraged not to create these affinities, particularly activity and process affinities, because these affinities are synchronized across the BTS-set. This could have serious performance impacts on your systems.
You should also note that, with CICSPlex SM, the longest time that an affinity can be maintained is while a CMAS involved in the workload is active; that is, an affinity of PERMANENT. If there is a total system failure, or a planned shutdown, affinities will be lost, but activities in CICS will be recovered from the BTS RLS data set.
The CICSPlex SM affinity services have no facilities for the management of affinities between enterprise beans. Transaction affinity relation and lifetime fields in the workload management views should be left blank.
For Link3270 bridge transactions, affinities are managed by CICS® and not by CICSPlex SM. Transaction affinity relation and lifetime fields in the workload management views should be left blank.
Figure 7 illustrates how you might separate the work in a workload based on transaction identifiers and then associate an affinity relation and lifetime with those transactions. With this example, the first occurrence of a transaction named PAY1, where the associated terminal and user names are NET1 and SMITH, respectively, is directed to the appropriate target region within the set of target regions identified as EYUCSG05. The specific target region receiving the transaction and the affinity relation and lifetime associated with the transaction group to which PAY1 belongs are noted. All subsequent occurrences of any transaction in the transaction group that meet the terminal and user name criteria are directed to the same target region for the designated period of time.