Duration and scope of inter-transaction affinities

When planning your dynamic routing strategy, and planning how to manage inter-transaction affinities, it is important to understand the concepts of affinity relations and affinity lifetimes. The relations and lifetimes of inter-transaction affinities must be taken into account when designing a dynamic or distributed routing program, because they define the scope and duration of inter-transaction affinities. Clearly, the ideal situation for a dynamic or distributed routing program is for there to be no inter-transaction affinities at all, which means there are no restrictions in the choice of available target regions for dynamic routing. However, even when inter-transaction affinities do exist, there are limits to the scope of these affinities, the scope of the affinity being determined by affinity relation and affinity lifetime.

Understanding the relations and lifetimes of transaction affinities is important in deciding how to manage them in a dynamic routing environment.

Affinity transaction groups

In order to manage affinities within a dynamic routing environment, you must first categorize transactions by their affinity. One way to do this is to place transactions in groups, where a group is a set of transactions that have inter-transaction affinity. Each affinity transaction group (or affinity group, for short) thus represents a group of transactions that have an affinity with one another. Defining affinity groups is one way that a dynamic or distributed routing program can determine to which target region a transaction should be routed.

Clearly, the more inter-transaction affinity you have in a given CICS® workload, the less effective a dynamic routing program can be in balancing the workload across a CICSplex. To minimize the impact of inter-transaction affinity, affinities within an affinity group can characterized by their relation and lifetime. These relation and lifetime attributes determine the scope and duration of an affinity.

Thus, ideally, an affinity transaction group consists of an affinity group identifier, a set of transactions that constitute the affinity group, with the affinity relation and affinity lifetime associated with the group.

Relations and lifetimes

When you create an affinity group, you should assign to the group the appropriate affinity relation and affinity lifetime attributes. The relation determines how the dynamic or distributed routing program is to select a target region for a transaction instance associated with the affinity, and the lifetime determines when the affinity is ended.

There are four possible affinity relations that you can assign to your affinity groups:

  1. Global
  2. LUname
  3. Userid
  4. BAPPL

These are described in the following sections, together with the permitted lifetimes for each relation.

The global relation

A group of transactions whose affinity relation is defined as global is one where all instances of all transactions in the group that are initiated from any terminal, by any START command, or by any CICS BTS process, must execute in the same target region for the lifetime of the affinity. The affinity lifetime for global relations can be as follows:

System
The affinity lasts for as long as the target region exists, and ends whenever the target region terminates (at a normal, immediate, or abnormal termination).
Permanent
The affinity extends across all CICS restarts. This is the most restrictive of all the inter-transaction affinities. If you are running CICSPlex® SM, this affinity lasts for as long as any CMAS involved in managing the CICSplex using the workload is active.

An example of a global inter-transaction affinity with a lifetime of permanent is where the transaction uses (reads and/or writes) a local, recoverable, temporary storage queue, and where the TS queue name is not derived from the terminal. (You can only specify that a TS queue is recoverable in the CICS region in which the queue is local.)

Generally, transactions in this affinity category are not suitable candidates for dynamic routing and you should consider making them statically routed transactions.

An example of a global relation is illustrated in Figure 69.

Figure 69. Managing inter-transaction affinity with global relation and permanent lifetime
 An example showing a transaction with a permanent global affinity relation, routed as described in the following text.

In this example, the transaction GGGG is defined in a group with a permanent global affinity relation. The first instance of transid GGGG, from any terminal, starts a permanent-lifetime affinity. The first instance of GGGG can be routed to any suitable target region. In this example, AOR2 is selected from the possible range AOR1 through AOR6, but all other instances, from any terminal, must also be routed to the same region, AOR2.

The LUname (terminal) relation

A group of transactions whose affinity relation is defined as LUname is one where all instances of all transactions in the group that are associated with the same terminal must execute in the same target region for the lifetime of the affinity. The affinity lifetime for LUname relations can be as follows:

Pseudoconversation
The affinity lasts for the whole pseudoconversation, and ends when the pseudoconversation ends at the terminal. Each transaction must end with an EXEC CICS RETURN TRANSID, not with the pseudoconversation mode of END.
Logon
The affinity lasts for as long as the terminal remains logged-on to CICS, and ends when the terminal logs off.
System
The affinity lasts for as long as the target region exists, and ends whenever the target region terminates (at a normal, immediate, or abnormal termination).
Permanent
The affinity extends across all CICS restarts. If you are running CICSPlex SM, this affinity lasts for as long as any CMAS involved in managing the CICSplex using the workload is active.
Delimit
The affinity continues until a transaction with a pseudoconversation mode of END is encountered.

A typical example of transactions that have an LUname relation are those that:

These types of transaction can be placed in an affinity group with a relation of terminal and lifetime of pseudoconversation. When the dynamic routing program detects the first transaction in the pseudoconversation initiated by a specific terminal (LUname), it is free to route the transaction to any target region that is a valid candidate for that transaction. However, any subsequent transaction within the affinity group that is initiated at the same terminal must be routed to the same target region as the transaction that started the pseudoconversation. When the affinity ends (at the end of the pseudoconversation on a given terminal), the dynamic routing program is again free to route the first transaction to any candidate target region.

This form of affinity is manageable and does not impose too severe a constraint on dynamic transaction routing, and may occur commonly in many CICSplexes. It can be managed easily by a dynamic routing program, and should not inhibit the use of dynamic routing.

This example is illustrated in Figure 70.

Figure 70. Managing inter-transaction affinity with LUname relation and pseudoconversation lifetime
 An example showing transaction AAAA from terminal with LUNAME IGKS201 in a group with a pseudoconversation luname relation, routed as described in the following text.

In this example, each instance of transid AAAA from a terminal starts a pseudoconversational-lifetime affinity. AAAA can be routed to any suitable target region (AOR1 through AOR6), but other transactions in the group, in the same pseudoconversation with the same terminal (IGKS201 in this example) must be routed to whichever target region is selected for AAAA.

The userid relation

A group of transactions whose affinity relation is defined as userid is one where all instances of the transactions that are initiated from a terminal, by a START command, or by a CICS BTS activity, and executed on behalf of the same userid, must execute in the same target region for the lifetime of the affinity. The affinity lifetime for userid relations can be as follows:

Pseudoconversation
The affinity lasts for the whole pseudoconversation, and ends when the pseudoconversation ends for that userid. Each transaction must end with an EXEC CICS RETURN TRANSID, not with the pseudoconversation mode of END.
Signon
The affinity lasts for as long as the user is signed on, and ends when the user signs off. Note this lifetime is only possible in those situations where only one user per userid is permitted. Signon lifetime cannot be detected if multiple users are permitted to be signed on with the same userid at the same time (at different terminals).
System
The affinity lasts for as long as the target region exists, and ends whenever the target region terminates (at a normal, immediate, or abnormal termination).
Permanent
The affinity extends across all CICS restarts. If you are running CICSPlex SM, this affinity lasts for as long as any CMAS involved in managing the CICSplex using the workload is active.
Delimit
The affinity continues until a transaction with a pseudoconversation mode of END is encountered.

A typical example of transactions that have a userid relation is where the userid is used dynamically to identify a resource, such as a TS queue. The least restrictive of the affinities in this category is one that lasts only for as long as the user remains signed on.

An example of an affinity group with the userid relation and a signon lifetime is shown in Figure 71.

Figure 71. Managing inter-transaction affinity with userid relation and sign-on lifetime
 An example of a transaction in a group with a lifetime sign-on affiniy relation, routed as described in the following text.

In this example, any instance of a transaction from a terminal starts a sign-on lifetime affinity. It can be routed to any suitable target region (AOR1 through AOR6), but other transactions in the group for the same user (ANOTHER in this example) must be routed to whichever target region is selected for the first instance of a transaction in the group.

The BAPPL relation

A group of transactions whose affinity relation is defined as BAPPL is one where all instances of all transactions in the group that are associated with the same BTS process are to be directed to the same target region. The affinity lifetimes for BAPPL relations can be as follows:

Process
The affinity lasts for as long as the associated process exists.
Activity
The affinity lasts for as long as the associated activity exists.
System
The affinity lasts for as long as the target region exists, and ends whenever the target region terminates (at a normal, immediate, or abnormal termination).
Permanent
The affinity extends across all CICS restarts. If you are running CICSPlex SM, this affinity lasts for as long as any CMAS involved in managing the CICSplex using the workload is active.

A typical example of transactions that have a BAPPL relation is where a local temporary storage queue is used to pass data between the transactions within a BTS activity or process.

An example of an affinity group with the BAPPL relation is shown in Figure 72.

Figure 72. Managing inter-transaction affinity with BAPPL relation and activity lifetime
 An example of a BTS transaction with an activity BAPPL relation, routed as described in the following text.

In this example, the first instance of BTS transaction BAP1 starts a BAPPL-activity affinity. The first instance of BAP1 can be routed to any suitable target region (AOR1 through AOR6), but all other instances of the activity must be routed to whichever target region is selected for BAP1.

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.

[[ Contents Previous Page | Next Page Index ]]