Although The Evans Group no longer consults, the web site lives on!

CICS TS 2.2 And Threadsafe
(Excerpted from Technical Support, the journal of NaSPA)
 

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).

Background
 

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 duplicate keys.

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 Threadsafe.

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.

Controlling Threadsafe.
 

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 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.

Recommendations

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 CPU overhead.
 

Futures
 

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 future.

For more information, please visit the threadsafe page on my website, www.evansgroupconsulting.com/spec.html

P. O. Box 323  Mount Vernon, Me 04352