I am a CICS sysprog and implemented Threadsafe at our
CPU savings are usually significant. It is definitely a YMWV
Mileage Will Vary) situation based upon your version of CICS and
application's characteristics and usage patterns. The later
CICS (2.3 and 3.1) offer more Threadsafe improvements than 2.2
CICS commands have been made "Threadsafe".
The key issue here is avoiding TCB switches. One TCB switch is
expensive (I believe in the sub-millisecond range), but if the
does significant DB2 I/Os, all of those TCB switches begin to add
Using Threadsafe reduces the CPU consumption of most DB2
running in CICS by avoiding many of these collectively expensive
Main factors governing the CPU reduction of a given
1) Number of DB2 I/O operations (Without Threadsafe, there are
TCB switches for each DB2 I/O, each of which corresponds to a call
by CICS. One TCB switch is from the QR TCB to the L8 TCB; after the
returns, CICS switches the task back to the QR TCB)
2) Amount of CPU consumed by the application. If the application
a lot of CPU and does few DB2 I/Os, the savings will be relatively
the application consumes relatively little CPU and does relatively
I/Os, the savings will be relatively greater.
3) Proportion of non-Threadsafe commands executed. Certain CICS
depending upon the particular release of CICS, are not Threadsafe.
accomodates them by doing two TCB switches each time they are
Therefore, executing non-Threadsafe commands while running in
mode offsets some of the benefits of running Threadsafe.
4) Running non-Threadsafe exits in CICS, depending upon when they
task lifetime and how frequently they are executed, can also
Threadsafe benefits by causing extra TCB switches. Because the task
starts on the QR TCB, even when running in Threadsafe mode, exits
early in task lifetime, before the first DB2 I/O, are not an
Not receiving expected benefits from Threadsafe can mean issues
applications, issues with exits running in CICS, or an application
has low potential to benefit (either very few DB2 I/Os--not very
high task CPU consumption with relatively fewer DB2 I/O
If you are curious about the potential benefits, turn Threadsafe
in an isolated test region and have one user (one user only) run
typical applications and check your CICS monitoring product for
consumption and the number of TCB switches compared with running
Threadsafe. If the benefits are disappointing, a CICS sysprog
review the exits running in CICS, the results, and the application
It is important to review applications for code which is not
Threadsafe before turning on Threadsafe for a particular
program. Failure to do so can have "unpredictable" results, which
means weird application errors. Threadsafe allows programs to
simultaneously within a given CICS region, not possible before.
using such techniques as shared storage (Getmain Shared), Address
others is not permitted because of integrity issues.
I was very pleased with the benefits of Threadsafe, one of the
features introduced in CICS recently. It was a signficant CPU
for relatively little work. Most tuning changes produce much less
reduction for more work.
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives
and home page at http://www.idugdb2-l.org/archives/db2-l.html.
From that page select "Join or Leave the list". The IDUG DB2-L FAQ
is at http://www.idugdb2-l.org.
List Admins can be reached at [login to unmask email] Find
out the latest on IDUG conferences at http://conferences.idug.org/index.cfm