|
Although The Evans Group no longer consults, the web site lives on!
CICS TS 2.2 And Threadsafe: Making
Programs Threadsafe
(Excerpted from Technical Support, the journal
of NaSPA)
In my previous article, CICS TS 2.2 and Threadsafe (Technical
Support, August 2003), I discussed the evolution of multitasking in
CICS, and how the implementation of the Open Transaction Environment
allowed threadsafe programs to run in a true multitasking
environment. This article picks up where I left off, and discusses
the ins and outs of converting programs to threadsafe.
Simply put, a threadsafe program doesn't access any shared storage
areas without serializing the access first. Unfortunately, there is
no automated way of telling if a program is threadsafe or not. Since
defining a program as threadsafe when it is not truly threadsafe can
result in data corruption and "unpredictable results", the
programmer has to know how to manually review programs, identify
non-threadsafe code, and modify it to be threadsafe.
Identifying Application Candidates
When deciding which applications would most benefit from the use of
threadsafe, there are three major areas to consider.
First and most importantly, before any application can be considered
for threadsafe conversion, the CICS regions in question must be
capable of supporting a threadsafe environment. All of the exits in
the regions must be reviewed. While certain low-use exit points
could remain quasi-reentrant without impacting the performance of
threadsafe applications, it is critical that all high- and
medium-use exits be converted to threadsafe before any application
program.
After converting the exits, the second task is to identify which DB2
applications to convert and in what order -- DB2 applications are
the obvious first choice, as converting a DB2 application to
threadsafe has the potential for significant CPU savings.
Applications with the greatest number of SQL calls per transaction
have the greatest potential CPU savings, but a compact,
self-contained application makes a good choice for the first
implementation.
While DB2 applications can make use of the OTE automatically, the
advantages of OTE are available to all programs through the OPENAPI
Task Related User Exit. Programs that would most benefit from this
are those that:
o Are heavy users of CPU
o Currently make use of OS functions that are restricted in CICS
o Currently manage their own TCB
Converting Programs to Threadsafe
When reviewing programs, it is important to remember that there is
no automated method to tell if a program is threadsafe, or to
convert a program. However, there are a few rules of thumb and an
IBM tool that can help.
First, pre-LE COBOL programs can not be made threadsafe.
Second, programs must be re-entrant to be threadsafe. COBOL programs
compiled with RENT are automatically re-entrant; re-entrancy for
assembler programs can be easily verified by linking the program as
RENT, and setting RENTPGM=PROTECT. If the program isn't re-entrant
it will abend ASRA.
Third, applications that have no transaction affinities are more
likely to be threadsafe than applications with affinities.
IBM supplies a source module scanner to help identify potentially
non-threadsafe programs. The scanner, DFHEISUP, 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.
While DFHEISUP is helpful in the process of identifying threadsafe
applications, it is critical to have a solid understanding of the
application in question. Each program that shows up in the DFHEISUP
report must be reviewed; if the area flagged in the report is
actually used by the program, determine if the use would make the
program non-threadsafe. Also, review all calls, links and xctl's
from the program to see if addressability to the area is being
passed to other programs; if it is, then those programs must also be
reviewed.
Converting Non-Threadsafe Code
Once the program review has been completed, and the non-threadsafe
code has been identified, what remains is to decide what to do.
There are three basic methods of dealing with non-threadsafe code:
The first alternative is to do nothing.
While it may seem counter-intuitive, sometime the best thing to do
is to leave the code as it is. In some cases, the data may no longer
be used, or the data may not need to be completely accurate. For
example, one of the first applications I converted to threadsafe
maintained statistics in a shared storage area. These statistics
were implemented by the programmer who had added a new
data-compression feature to the application, and were used to keep
track of how well the compression was working. At the time of the
threadsafe conversion, the data-compression had been in place for
over a year, and no one was concerned with how well it worked. I
updated the documentation to state that the compression statistics
were no longer reliable, and left the code unchanged.
Another rational for doing nothing is if the non-threadsafe code is
totally contained within a small percentage of the programs in an
application. In this case, the non-threadsafe programs can remain as
QUASIRENT while the rest of the application is changed to
THREADSAFE. CICS will automatically handle switching transactions
back to the QR TCB when one of the non-threadsafe programs is linked
or xctl'ed to, thus serializing the data access. Remember that every
program that access any of these non-serialized storage areas must
remain QUASIRENT for this process to work correctly; if any program
containing a non-serialized storage access is marked as THREADSAFE,
then all of the programs accessing that area are at risk.
The second alternative is to move the data.
CICS offers a number of alternatives to shared storage that are
fully serialized, including Temporary Storage, DB2 tables, VSAM
files, Data Tables and the Coupling Facility. Relocating the
offending data to one of these areas will remove the non-threadsafe
activity. These areas have the additional benefit of being sharable
between regions, thus allowing the removal of a transaction affinity
at the same time as making the application threadsafe. For high-use
data, the option of CICS Maintained Data Tables is particularly
popular, as it provides quick access with less overhead than some of
the other options.
The final alternative is to serialize the data.
If the data cannot be moved, then the only other option is to add
code to manually serialize access to it. CICS provides the EXEC CICS
ENQ/DEQ commands to provide serialization, but they add overhead and
can result in deadly embraces. If the decision is made to utilize
ENQ/DEQ, care must be taken to follow standard design practices and
ensure that multiple areas are serialized on in the same order, and
that enqueues are released as soon as is possible. When utilizing
enqueues, you need to decide if read-only access to each area must
be serialized, or only update access.
A second alternative for serialization is use of the Compare and
Swap assembler instruction. CS (and it's cousin, Compare Double and
Swap) provide serialized memory access at the hardware level; for
the duration of the CS instruction, no other processor on the
machine is allowed to access the storage area in question. Compare
and Swap can be confusing the first time it's used; see figure 1 for
an example.
Achieving Maximum CPU Savings
Since one of the main selling points of CICS TS 2.2 was the
potential CPU savings from converting DB2 applications to
threadsafe, many threadsafe conversion projects are being driven
from a cost-reduction perspective. As such, it is important to
understand how the CPU reduction is achieved, and what can inhibit
the savings.
DB2 system code has always executed in a separate TCB from the QR.
Threadsafe does not change that. What threadsafe changes is that the
DB2 code no longer has to spin itself back to the QR TCB before
returning control to the calling program. Instead, the calling
program continues to run on DB2s TCB (called the "L8" TCB) , meaning
that the second SQL call no longer has to be spun back to the DB2
TCB. Eliminating these TCB switches is where the CPU savings comes
from.
The problem is that not all code is threadsafe. Some of this
non-threadsafe code is in application programs; if a threadsafe
program LINKs or XCTLs to a non-threadsafe program, the task is spun
back to the QR TCB, where it will remain until the next SQL call. In
the same way, some CICS commands are not threadsafe; if a threadsafe
program issues a non-threadsafe EXEC CICS command, the task is
handled in the same manner. In either case, the task suffers an
additional TCB switch, resulting in less CPU savings; in a
worst-case scenario, no CPU savings would be produced at all.
Earlier in this article, I stated that the CICS Global and Task
Related User Exits had to be converted to threadsafe before
attempting to convert any application. The reason is that
non-threadsafe exits are not handled in the same way as
non-threadsafe CICS commands or user programs. Instead of being spun
back to the QR TCB until the next SQL command, the task is only
placed on QR for the duration of the exit program. The task is then
sent back to the L8 TCB. If the exit point is a common one (such as
XEIIN, called on entry to every EXEC CICS command) the number of TCB
switches the task undergoes will rise dramatically, resulting in a
significant increase in CPU utilization.
Once your application has been converted to threadsafe, you can
verify that you are meeting your CPU savings potential by checking
the SMF stats for the application and comparing the ratio of TCB
swaps ("Mode Switches") to SQL calls. A high number indicates either
non-threadsafe exits, or non-threadsafe CICS commands interleaved
with the SQL statements. The best method of identifying the culprit
is the CICS Aux Trace, which will show the TCB switch as a DSAT
CHANGE_MODE MODENAME(QR) or (L8) just after the entry for the
non-threadsafe command. If you find that use of non-threadsafe
commands is limiting the CPU reduction from threadsafe, your only
option is to change the application code. It is sometimes possible
to remove the command (for example, if an ASKTIME is being used when
EIBTIME would be sufficient); or replace a non-threadsafe use with a
threadsafe alternative (moving from a VSAM scratchpad file to Temp
Storage, for example); if the command can't be removed or replaced,
it may be possible to move it outside of the SQL loop, so that it
doesn't generate additional TCB switching. The list of threadsafe
commands is documented in appendix L of the CICS Application
Programmer's Reference Manual. IBM has stated a desire to make more
commands threadsafe, but has set no timetable.
Note that if the ratio of TCB swaps to SQL calls is greater than
one, one of your exits is not threadsafe.
Recommendations
Before starting to convert any of your applications to threadsafe,
you must convert your CICS exit programs. Contact your system
software vendors (and your application vendors, if any of your
purchased applications use exits) to see when they will have
threadsafe versions available. If they are not planing to convert
their exit programs, review the affected exit points in the
Customization Guide to see when they are called (a non-threadsafe
dump control exit would not be as much of a problem as the XEIIN
exit point mentioned previously, for example.) Do not attempt a
threadsafe conversion in a region with a high-use non-threadsafe
exit program.
Remember to attempt to identify the most promising applications to
start with. If possible, chose applications with the greatest number
of DB2 calls per transaction to maximize the potential savings.
Review an aux trace of the more heavily used programs, to see if
there are non-threadsafe commands interleaved with the DB2 calls.
IBM recommends that the following maintenance be applied before
running threadsafe:
PQ75405, PQ67351, PQ72112, PQ67559, PQ67863, PQ67892, PQ68099,
PQ69553
One last item, which is not actually related to threadsafe, but has
caused a lot of consternation in DB2 users. In CICS TS 2.2, SMF user
cputime now includes DB2 cputime.
For more information, please visit the threadsafe page on my
website, www.evansgroupconsulting.com/spec.html
P. O. Box 323 Mount Vernon, Me 04352 |