There are two ways to control the use of threadsafe in a CICS region. On the program definition, a new parameter has been added: concurrency. CONCURRENCY=QUASIRENT indicates the program must run on the QR TCB; CONCURRENCY=THREADSAFE marks a program as threadsafe, allowing it to run on an open TCB. Be aware that marking a program as threadsafe doesn’t make it threadsafe; the programmer uses this parameter to define programs that have proved to be threadsafe.
The second control is at the region level. Specifying FORCEQR=YES in the SIT will override the CONCURRENCY parameter on the program definitions to force all programs to run on the QR TCB.
Before marking any program as threadsafe, all Task Related and Global User Exits (TRUEs and GLUEs) that are active in the region must be reviewed to ensure they’re threadsafe-compliant and defined as threadsafe. Activating threadsafe programs in a region with non-threadsafe exits can result in a significant increase in CPU utilization.
Ensuring Threadsafe Compliance
All threadsafe programs must be re-entrant. LE programs can be guaranteed re-entrant by compiling with the RENT option; Assembler programs can be easily tested for re-entrancy by linking with the RENT option and then running in a CICS region with RENTPGM=PROTECT. Non-re-entrant programs will abend with an S0C4 when they attempt to modify themselves. It’s strongly recommended that all CICS regions running threadsafe programs use RENTPGM=PROTECT.
Unfortunately, there’s no automated way to identify non-threadsafe program code. IBM does supply a utility, DFHEISUP, that can be useful in identifying potential non-threadsafe programs. It works by scanning application load modules, looking for occurrences of commands found in member DFHEIDT. (Details appear in the CICS Operations and Utilities Guide.) DFHEISUP will report, for example, that a program issues an ADDRESS CWA command. Since the CWA is often used to maintain counters or address chains, a program addressing the CWA could be using it in a non-threadsafe manner. On the other hand, the program could also be using the CWA to check for operational flags, file Data Definition (DD) names, or other uses that don’t raise threadsafe issues. More worrisome, DFHEISUP could report no hits on an application program, leading you to believe the program was threadsafe, when the program was in fact maintaining counters in a shared storage location whose address is passed in the incoming commarea.
While DFHEISUP is helpful in the process of identifying threadsafe applications, the only way to ensure an application is threadsafe is to have a competent programmer review it in its entirety.
Making Programs Threadsafe
It’s possible for a program to access shared storage areas such as the CWA while remaining threadsafe-compliant. Each shared storage access must be reviewed independently to determine its status. Accesses that require update integrity or repeatable read integrity (counters, in-core tables, pointers, etc.) aren’t threadsafe-compliant and must be serialized before running in a threadsafe region.
Various serialization options are available to CICS programmers: