IBM OS Safe programming techniques, Unsafe programming techniques, Suspect programming techniques

Models: OS

1 103
Download 103 pages 52.71 Kb
Page 22
Image 22

 

Safe programming techniques

 

 

The programming techniques in the safe category are the use of:

 

 

v The communication area (COMMAREA) on CICS RETURN commands

 

 

v A terminal control table user area (TCTUA) optionally available for each terminal

 

 

de®ned to CICS

 

v ENQMODEL de®nitions to give sysplex-wide scope to ENQs and DEQs

 

Unsafe programming techniques

 

 

The programming techniques in the unsafe category are the use of:

 

 

v Long-life shared storage:

 

 

± The common work area (CWA)

 

 

± GETMAIN SHARED storage

 

 

± Storage obtained via a LOAD PROGRAM HOLD

 

 

v Task-lifetime local storage shared by synchronized tasks

 

 

v Synchronization or serialization of tasks using CICS commands:

 

 

± WAIT EVENT / WAIT EXTERNAL / WAITCICS commands

 

± ENQ and DEQ commands that do not specify a length parameter and

 

therefore ENQ by address

 

± ENQ and DEQ commands that do specify a length and therefore ENQ by

 

name, unless you have used ENQMODEL de®nitions to give sysplex-wide

 

scope to the ENQs (and DEQs)

 

Suspect programming techniques

 

 

Some programming techniques may 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 will work without restrictions in a dynamic routingenvironment.

 

 

The programming techniques in the suspect category are the use of:

 

 

v Temporary storage queues with restrictive naming conventions

 

v Transient data queues and trigger levels

 

 

v Synchronization or serialization of tasks using CICS commands:

 

 

± RETRIEVE WAIT / START

 

 

± START / CANCEL REQID

 

 

± DELAY / CANCEL REQID

 

 

± POST / CANCEL REQID

 

v INQUIRE and SET commands and global user exits

 

 

 

 

Avoiding the effects of transaction affinity

 

In a dynamic routing environment, your dynamic routing program must take account

 

of transaction affinity in order to route transactions effectively. Where possible, you

 

should avoid creating application programs that cause affinity. However, where

 

existing applications are concerned, it is important that you determine whether they

 

are affected by transaction affinity before using them in a dynamic routing

 

environment. The Transaction Affinities Utility is designed to help you with this task.

6 CICS Transaction Affinities Utility Guide

Page 22
Image 22
IBM OS manual Safe programming techniques, Unsafe programming techniques, Suspect programming techniques