An intertransaction affinity is a relationship between transactions, of a specified duration, that requires them to be processed by the same target region. For example, you might have a pseudoconversation made up of three separate transactions, and each transaction passes data to the next transaction in the sequence via a temporary storage queue (which may be shared in the distributed model). You would then specify that all three transactions must be processed by the same target region, and that this affinity lasts for the duration of the pseudoconversation. (If you did not define this affinity to CICSPlex® SM, each transaction could be routed to a different target region and would therefore be unable to access temporary-storage data left by the previous transaction.) The target region itself is selected by CICSPlex SM from the specified target scope.
Workload management and the IBM® CICS Interdependency Analyzer for z/OS®
understand affinities
between BTS processes and activities. BTS itself does not introduce affinities,
and discourages programming techniques that do, but it does handle existing
code that may introduce affinities. You should define such affinities to workload
management, so that it can make sensible routing decisions. It is particularly
important to specify each affinity’s lifetime; failure to do so may restrict
unnecessarily workload management’s routing options.
Workload management and the IBM CICS Interdependency Analyzer for z/OS
do not understand
affinities between routable non-terminal-related EXEC CICS START commands,
or between DPLs not associated with a user id or a terminal. You should take
steps either to remove any affinities from your applications, or to ensure
that your applications honor any affinities.
Note that, if data is passed between transactions via the COMMAREA on the EXEC CICS RETURN command, no such affinity exists: the COMMAREA is passed back to the requesting region, and so can be passed to the target selected to process the next transaction in the sequence. For more information about ways of avoiding or minimizing transaction affinities, see the CICS/ESA publication Dynamic Transaction Routing in a CICSplex.
When the first transaction from a group of related transactions is started, CICSPlex SM selects an appropriate region from the specified target scope. If there is more than one suitable region in the target scope, CICSPlex SM selects one using the current workload balancing algorithm. Subsequent transactions in the same group that meet the affinity criteria are directed to the same region as the first transaction. If subsequent transactions do not meet the affinity criteria (for example, if the same pseudoconversation is started from a different user ID), the selection process for a suitable region starts again.
[[ Contents Previous Page | Next Page Index ]]