Programming techniques and affinity

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.