When IBM announced support for running application code in the Open Transaction Environment (OTE), among the selling points was a significant reduction in CPU utilization in CICS-DB2 applications. Unfortunately, the possibility of reducing an application’s CPU requirements by 30 percent, without any coding changes, diverted attention from the OTE’s many other benefits. This article discusses those benefits and related OTE issues.
The OTE and threadsafe provide a significant architectural change to CICS. For the first time, CICS provides a true multi-processing environment running application code under multiple Task Control Blocks (TCBs) within the same CICS region.
Problems Caused by CICS Multi-Processing
In a standard CICS environment, all CICS application code runs under a single CICS TCB known as the Quasi-Reentrant (QR) TCB. (While all application code runs under the QR TCB, CICS maintains several specialty TCBs for use by CICS internal services.) Single-threading all user code lets CICS provide direct access to shared storage areas without requiring serialization. From the time CICS dispatches a task until the time a task issues an EXEC CICS request, the task is the sole owner of the entire CICS address space. For example, program PROG1 could safely read and increment a counter in the Common Work Area (CWA) because no other instances of PROG1 could be running concurrently.
Such single-threading doesn’t exist in the OTE. The CICS dispatcher initiates simultaneous tasks on multiple OTE TCBs whenever possible. The PROG1 program can no longer safely read or increment its CWA counter because multiple instances of PROG1 might also be reading and incrementing the counter simultaneously. PROG1 must be modified to use some manual serialization technique to replace the QR TCB serialization. Even when some user programs are enabled to run on an open TCB, the QR TCB continues to run single-threaded. This doesn’t eliminate shared storage serialization concerns for programs remaining on the QR TCB; programs running on open TCBs may access the shared storage simultaneously as a program on the QR TCB. Serialization must be maintained at the storage area level, not at the program level.
A program that serializes all access to shared storage, or doesn’t rely on any area of shared storage remaining consistent between machine instructions, is described as being threadsafe. Only threadsafe programs run safely in a multi-tasking environment.
Limiting all user code to the QR TCB has many disadvantages, including:
- Restricts use of OS system calls in user code. When code runs on the QR TCB, it controls the CICS region completely. Any OS call that causes a wait will halt the entire region; OS calls that alter the TCB state will alter the entire region state.
- Restricts all user code to run serially on one processor. A single TCB can’t run any faster than the speed of a single processor. In today’s multi-processor environment, a CICS QR TCB is limited to only a small percentage of the processing capacity of the Logical Partition (LPAR) on which it runs. This can result in the seemingly paradoxical event of a production CICS running slower after being moved to a faster machine. If the new machine has a larger total MIPS capacity due to more, but slower, processors, CICS’ one-processor limit will reduce the CICS region’s CPU capabilities.
- CPU-intensive tasks block out the CICS dispatcher. When a user program is dispatched on the QR TCB, it controls the region. After passing control to the user program, the CICS dispatcher doesn’t receive control until the user program issues an EXEC CICS command. While CICS will receive control at every EXEC CICS command, not all commands activate CICS’ dispatching process. Some commands, such as ASKTIME, are processed so quickly that CICS bypasses the dispatcher and returns control directly to the calling program. In this case, a CPU-intensive program will continue to block the dispatcher until it issues an EXEC CICS command that returns control to the dispatcher.
- If the program is CPU-intensive, the next EXEC CICS command won’t be issued for an unusually long time, resulting in what appears to be a regionwide slowdown.
The OTE resolves these problems by accommodating separation of user code from the QR TCB. When a program runs in the OTE:
- The limitation on issuing OS system calls is lifted because any resulting wait only affects the open TCB on which the task is running. The only documented restriction on OS activity by a program running in the OTE is that it must not attempt to initialize the batch Language Environment (LE).
- The inability to exploit multiple processors is removed; z/OS will dispatch open TCBs on any available processor. CICS no longer runs slower on a faster machine.
- CPU-intensive tasks now block only the open TCB they’re running on, leaving all other open TCBs (and the QR TCB) available for useful work, eliminating the slowdown.
Open TCB Types