Although The Evans Group no longer consults, the web site lives on!
CICS TS 2.2 And Threadsafe
(Excerpted from Technical Support, the journal
One of the many selling points of CICS Transaction
Server V2.2 has been the potential of significant CPU reduction for
CICS/DB2 transactions that can be made "threadsafe" (see IBM
Software Announcement 201-354.) Unfortunately, ensuring that a
program is threadsafe is difficult because the concept of threadsafe
is completely new in the CICS environment. This article will provide
background on what threadsafe means at the program level, and also
on the most significant enhancement to CICS since its creation: the
Open Transaction Environment (OTE).
When CICS was first introduced, it ran as a single operating system
task. Once the CICS dispatcher had given control to a user program,
that program had complete control of the entire region until it
requested a CICS service. If the program issued a command that
included an OS wait, the entire region would wait with it. As a
result, the CICS documentation included a list of OS (and later,
COBOL) commands that could not be used by CICS programs. At the same
time, there was a significant advantage to this design in that
programs did not have to be re-entrant between CICS commands.
As all activity within the CICS region was single-threaded, it was
also restricted to the capacity of one CPU. The introduction of
multiprocessor mainframes brought new issues for the CICS systems
staff, when the purchase of a faster (and more expensive!) mainframe
resulted in a slowdown of CICS because the individual processors
were slower. IBM responded by attempting to offload some of the CICS
workload to additional MVS TCBs that would be able to run
concurrently on a multiprocessing machine. For convenience, IBM
labeled the main CICS TCB as the Quasi-Reentrant, or QR TCB.
The most significant implementation of this type of offloading came
with the introduction of the DB2 database. Rather than establishing
a TCB for all DB2 activity, CICS would create a separate TCB for
each concurrent DB2 request. Theoretically, while the application
programs for each task in the region still ran single-threaded, each
task's DB2 workload could be running simultaneously, limited only by
the total capacity of all the processors in a multiprocessor. On a
practical level, the DB2 workload seldom approached the CICS
workload, meaning that CICS was still constrained by the processing
speed of a single processor. In addition, since CICS had to switch
the transaction between the QR TCB and the DB2 TCB for each DB2
request, there was measurable overhead for complex DB2 applications.
Open Transaction Environment
To enable CICS to further exploit a multiprocessor and at the same
time remove the OS restrictions to which CICS programs are still
subject, IBM developed the Open Transaction Environment. Put simply,
OTE allows an individual CICS transaction to run under its own MVS
TCB instead of sharing the QR TCB. Many transactions, each under
their own TCB, can run at the same time within the same CICS region.
If a transaction running in the OTE issues an OS WAIT, none of the
other transactions in the CICS will be effected.
The drawback of OTE is that more than one occurrence of the same
program can run at the same time, leading to concurrency issues. A
simple example of the type of problem created is the common practice
of maintaining a record counter in the CWA that is used to create a
unique key. Under "classic" CICS, as long as the record counter was
updated before the next CICS command was issued, the integrity of
the counter was assured. With OTE, it is possible for two or more
transactions to use the counter at the same time, resulting in
It was to classify this type of problem that the term Threadsafe was
developed. Each OTE TCB is considered a Thread, so Threadsafe simply
means that the program is safe to run on an OTE thread.
It is crucial to remember that Threadsafe is not a determination
made by CICS, but a promise made by the programmer. By marking a
program as threadsafe, the programmer is stating that the program
will not cause any damage if it is allowed to run in the OTE.
OTE and DB2
The first (and currently, only) implementation of the Open
Transaction Environment is for DB2 applications. Where in prior
releases the application task would be switched to a DB2 TCB for DB2
work, and then immediately returned to the QR TCB, tasks will now
remain on the DB2 TCB until they either terminate or issue a
non-threadsafe command.* IBM has demonstrated significant CPU
savings in large DB2 shops from the resulting decrease in TCB
switches. This CPU savings is reduced if the application program
issues non-Threadsafe commands, and can be completely eliminated (or
even turned into a CPU increase) if CICS Global User Exits are not
Determining If A Program Is Threadsafe
One of the prereqs for Threadsafe is that the program must be
reentrant. LE programs can be guaranteed reentrant by compiling with
the RENT option; assembler programs can be easily tested for
reentrancy by linking with the RENT option and then running in a
CICS region with RENTPGM=PROTECT. Non-reentrant programs will abend
with a S0C4 when they attempt to modify themselves.
There is no automated way to identify Threadsafe programs.
IBM does supply a utility that can be useful in identifying
potential non-Threadsafe programs, DFHEISUP, which works by scanning
application load modules looking for occurrences of commands found
in member DFHEIDTH. Details of this utility can be found 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 DD names, or other uses that do not raise
Threadsafe issues. More worrisome, DFHEISUP could report no hits on
an application program, leading one to believe that the program was
threadsafe, when the program was 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 that an application is
Threadsafe is to have a competent programmer who is familiar with
the application review it in its entirety.
There are two ways to control the use of Threadsafe in a CICS
On the program definition, a new parameter has been added,
CONCURRENCY. CONCURRENCY=QUASIRENT indicates that the program uses
the QR TCB; CONCURRENCY=THREADSAFE marks a program as Threadsafe. Be
aware that marking a program as Threadsafe does not make it
Threadsafe; this parm is used by the programmer to mark programs
that have been proven Threadsafe.
The second control is at the region level. Specifying FORCEQR=YES in
the SIT will override the CONCURRENCY parm on the program
definitions to force all programs to run as QUASIRENT.
Making Programs Threadsafe
Once a program has been identified as non-threadsafe, there are two
alternatives: serialize the shared access, or do nothing.
It is possible to leave all programs in an application that access
shared storage as non-Threadsafe. Since these programs will run
under the QR TCB, they will be able to take advantage of the
serialization of "classic" CICS without any changes. A LINK or XCTL
to a non-threadsafe program from a Threadsafe program running under
an OTE TCB will result in a task switch, in much the same way as the
use of a non-threadsafe CICS command. If access to shared resources
is relatively infrequent and restricted to a small number of
programs, this is a reasonable approach that can still provide the
CPU savings Threadsafe offers. Care must be taken in a mixed
environment to ensure that program definitions are correctly
maintained and documented. Remember that Global and Task Related
user exits can have a more significant impact on performance, and
should be converted to Threadsafe if possible.
Once the decision to convert a program to threadsafe is made, there
are a number of serialization methods available. Determining which
method to use will depend on the use of the shared storage. First,
check to see if the use of shared storage can be eliminated; perhaps
a Temporary Storage queue or DB2 table could be used to store the
data. If the date must remain in shared storage, a CICS ENQ can be
used to force serialization, or for assembler programs, a Compare
and Swap. Avoid the temptation to use an OS service such as ENQ, as
it is not possible to guarantee that the transaction will still be
running in the OTE when the OS command is issued.
Remember that threadsafe programs may issue non-threadsafe CICS
commands safely. There is minor CPU overhead because CICS will
switch the task back to the QR TCB, but it is possible to achieve
CPU savings even with the use of non-threadsafe commands.
If you do not use DB2, the issue of Threadsafe is not of concern at
this time, but should not be ignored.
If you do use DB2, the CPU savings that are possible with Threadsafe
make it worth you time to investigate your applications. Be sure to
review your application in its entirety: modifying PROGA to use CICS
ENQ when updating a counter in the CWA will not stop PROGB from
updating the same counter without using an ENQ. Do not leave vendor
packages out of the picture: having CICS exits that are defined as
non-Threadsafe in a Threadsafe environment can result in significant
The OTE promises to change the way we look at CICS, by providing
full support for restricted OS commands and potentially supporting
batch-type programming without degrading online performance.
Although IBM has not made any announcements on the subject, it is
safe to assume that the OTE will become more heavily used with
future releases of CICS. The time to start converting applications
to Threadsafe is now, to avoid converting against a deadline in the
For more information, please visit the threadsafe page on my
P. O. Box 323 Mount Vernon, Me 04352