TEG Mainframe






Contact Us

Resource Room



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.


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