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.
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.
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:
These are described in the following sections, together with the permitted lifetimes for each 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:
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.
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.
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:
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.
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.
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:
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.
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.
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:
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.
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 ]]