In terms of inter-transaction affinity, the programming
techniques used by your application programs in a dynamic or distributed
routing environment, can be classed as safe, unsafe, or suspect.
Safe techniques
Safe programming
techniques avoid the need for affinities. The programming techniques
in the safe category are:
- The use of the communication area (COMMAREA), supported by the CICS® API
on a number of CICS commands. However, it is the COMMAREA option on
the CICS RETURN command only that is of interest in a dynamic or distributed
routing environment regarding transaction affinity, because it is
the COMMAREA on a RETURN command that is passed to the next transaction
in a pseudoconversational transaction.
- The use of a TCT user area (TCTUA) that is optionally available
for each terminal defined to CICS.
- Synchronization or serialization of tasks using CICS commands:
- The use of containers to pass data between CICS Business Transaction
Services (BTS) activities. Container data is saved in an RLS-enabled
BTS VSAM file.
For more information about the COMMAREA and the TCTUA, see Programming techniques that avoid affinity.
Unsafe techniques
Unsafe programming
techniques are techniques that can require the creation of affinities.
The programming techniques in the unsafe category are:
- The use of long-life shared storage:
- The common work area (CWA)
- GETMAIN SHARED storage
- Storage obtained by a LOAD PROGRAM HOLD
- The use of task-lifetime local storage shared by synchronized
tasks
It is possible for one task to pass the address of some
task-lifetime storage to another task.
It may be safe for
the receiving task to use the passed address, provided the owning
task does not terminate. It is possible, but ill-advised, to use a
CICS task-synchronization technique to allow the receiving task to
prevent the sending task from terminating (or freeing the storage
in some other way) before the receiver has finished with the address.
However, such designs are not robust because there is a danger of
the sending task being purged by some outside agency.
See Sharing task-lifetime storage for more details.
- Synchronization or serialization of tasks using CICS commands:
For more information about unsafe programming techniques, see Programming techniques that create affinities.
Suspect techniques
Some programming
techniques might, or might not, create affinity depending on exactly
how they are implemented. A good example is the use of temporary storage.
Application programs using techniques in this category must be checked
to determine whether they work without restrictions in a dynamic or
distributed routing environment. The programming techniques in the
suspect category are:
- The use of temporary storage queues with restrictive naming conventions
- Transient data queues and the use of trigger levels
- Synchronization or serialization of tasks using CICS commands:
- RETRIEVE WAIT / START
- START / CANCEL REQID
- DELAY / CANCEL REQID
- POST / CANCEL REQID
- INQUIRE and SET commands and global user exits
For more information about suspect programming techniques, see Programming techniques that might create affinities.
Recommendations
The best way
to deal with inter-transaction affinity is to avoid creating inter-transaction
affinity in the first place. Where it is not possible to avoid affinities,
you should:
- Make the inter-transaction affinity easily recognizable, by using
appropriate naming conventions, and
- Keep the lifetime of the affinities as short as possible.
Even if you could avoid inter-transaction affinities by
changing your application programs, this is not necessary provided
you include logic in your dynamic and distributed routing programs
to cope with the affinities. Finally, you can statically route the
affected transactions.