From the point of view of inter-transaction affinity in a dynamic or distributed routing environment, the programming techniques used by your application programs can be considered in three broad categories:
The programming techniques in the generally safe category are:
For more information about the COMMAREA and the TCTUA, see Safe programming to avoid affinity.
The programming techniques in the unsafe category are:
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.
For more information about unsafe programming techniques, see Unsafe programming for affinity.
Some programming techniques may, or may 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:
For more information about suspect programming techniques, see Suspect programming for affinity.
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:
Even if you could avoid inter-transaction affinities by changing your application programs, this is not absolutely 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.
[[ Contents Previous Page | Next Page Index ]]