Previous articles (see the “References” section) discussed the tremendous benefits accrued from using the CICS Open Transaction Environment (OTE), ranging from improved multiprocessor exploitation to reductions in software license charges. In this final article, we take a closer look at the CPU savings seen in large CICS/DB2 applications after they’re converted to threadsafe, as well as the critical elements of a successful conversion, including:
• How to identify programs that offer the greatest potential savings
• How to determine the actual savings available compared to the potential savings
• How to identify non-threadsafe application or system code
• Common methods to convert non-threadsafe code to meet threadsafe standards
• When (and why) a two-phase threadsafe conversion is appropriate.
It’s important to remember that the OTE by itself doesn’t reduce CPU consumption. CICS/DB2 programs that aren’t defined as threadsafe require two task control block (TCB) spins for each DB2 request issued, while CICS/DB2 programs that are defined as threadsafe can often avoid any TCB spins when issuing a DB2 request. Threadsafe CICS/DB2 programs running in the OTE use less CPU because CICS does less work to support them.
The operating system services DB2 system code uses can’t run on the quasi-reentrant (QR) TCB, so IBM uses a task-related user exit (TRUE) to intercept an SQL call and move the requesting task to another TCB where the DB2 code can be processed safely. (Note: The restrictions on what processing can be performed on the QR TCB are discussed in detail in the previous articles in this series.)
Once DB2 has processed the request, the requesting task is moved back to the QR to continue executing, resulting in two TCB spins per request. When IBM converted these TCBs to L8 TCBs, it allowed threadsafe programs to remain on the L8 TCB after DB2 completed the call. If the program is still running on an L8 TCB when it issues another SQL call, no TCB spinning is required, resulting in CPU savings. The program could potentially remain on the L8 until it terminates, eliminating the requirement for all but the spin required to service the first SQL call. The program’s potential TCB spin reduction is equal to 2 x(Number of SQL calls - 1). It’s important to remember that while the examples shown relate to DB2, any OPENAPI-enabled TRUE would work this same way; if your shop uses IDMS, substitute the word “IDMS” wherever “DB2” appears in this article.
Unfortunately, these TCB spins aren’t always avoidable, because the task will be spun back to the QR if the application program issues a non-threadsafe CICS command. Not all CICS system code is written to threadsafe standards; for example, a portion of the system code used to process an EXEC CICS DELAY is non-threadsafe. CICS serializes non-threadsafe commands by always executing them on the QR TCB. If a program is running on an L8 and issues a DELAY, CICS recognizes the non-threadsafe command and spins the task to the QR. When control is returned to the program, it’s left on the QR, so a subsequent SQL call will result in the task being spun back to the L8. Threadsafe programs that issue non-threadsafe commands can’t achieve their full potential CPU savings. This is becoming less of a problem since the introduction of the OTE, as IBM has gradually converted the bulk of all EXEC CICS commands to be threadsafe, reducing the scope of this issue significantly.
Identifying Programs That Offer the Greatest Potential Savings
You can identify programs with the greatest potential savings by using CICS’s built-in monitoring capabilities, although any standard CICS monitoring tool will make the process faster and easier. CICS statistics are written to the SMF data sets and are processed using the IBM-supplied program DFH$MOLS. The output supplied by DFH$MOLS is much more detailed than required for our purposes here; we only want to look at the number of TCB switches this task required when processing compared to the number of DB2 requests, as shown in Figure 1. The field “DB2REQCT” shows the number of DB2 requests made; “USRCPUT” shows the total amount of CPU consumed by this task and the total number of TCB switches (29,763) encountered. In this example, we have a potential savings of more than 29,700 TCB switches from converting this task’s DB2 programs to threadsafe.
Determining Actual Savings vs. Potential Savings
The potential savings we’ve identified can be quite different from the actual savings received based on the number and location of non-threadsafe EXEC CICS commands in the programs executed. It would be easy to find the actual savings available to this task if we could simply re-define all the programs it uses to be threadsafe and then generate an updated DFH$MOLS report. We can’t do that in production—never define a program as threadsafe until you’ve completed a thorough threadsafe analysis—but we can do so in test, using the following guidelines:
• Set up an isolated test CICS environment where this test will be the only activity.
• Ensure that CICS monitoring is on in this test region.
• Re-define the transaction(s) in question to be a member of a transaction class.
• Set that transaction class to a maximum of one.
• Execute a pre-defined set of transactions that can be repeated.
• Alter the PROGRAM definitions for all the programs involved to CONCURRENCY=THREADSAFE.
• Re-run the previously executed set of transactions.
• Compare the number of DB2 requests and TCB switches between the first (non-threadsafe) and second (threadsafe) runs.