Nmedia - Fotolia
IBM's thread safety CICS feature reduces CPU usage, but could be at odds with another option to boost mainframe performance.
Years ago, DB2 calls in Customer Information Control System (CICS) involved switching between the quasi-reentrant (QR) task and a thread subtask. A few years later, IBM realized that programs following certain coding rules could run on the DB2 subtasks without having to make the switch. Thus IBM introduced thread safety and open (L8) tasks or task control blocks (TCB) to CICS for better mainframe performance.
Thread safety is basically a superset of reentrancy. Reentrant programs support multiple threads running through them simultaneously. Thread-safe modules have additional logic for serializing shared resources.
Administrators use CICS commands and the program definition CONCURRENCY attribute to signify a module's capabilities. Valid CONCURRENCY values are:
- QUASIRENT (default): The program is neither thread safe nor reentrant and must run on the QR TCB. If the program makes a DB2 call, CICS will switch to an open TCB and back.
- THREADSAFE: The program is written to thread-safety specifications and can safely run on an open TCB. The module may or may not start on an L8 task. If the program makes a DB2 call, CICS will switch to an L8 task if the program isn't already running on one. When the DB2 call completes, CICS allows execution to continue on the open TCB until it uses a non-THREADSAFE CICS facility. Once the non-THREADSAFE request completes, the task will stay on the QR TCB until the next DB2 call.
- REQUIRED: The program is written to thread-safety standards and CICS starts the program on an open TCB. If the program uses a non-thread-safe facility, CICS switches the task to the QR TCB and back.
Thread safety boosts performance for CICS DB2 applications because it avoids bouncing between the QR and open tasks. It can also help non-DB2 applications because multithreading increases the throughput of a single CICS instance. This aligns with IBM's recommendation that doing more work in fewer address spaces is the best way to exploit the newer mainframe processors.
Calling language environment programs
Inside CICS, there are two straightforward ways of passing control between language environment (LE) commands and native program calls.
CICS LINK commands are pretty simple and pass data between programs in either communication areas or containers. Each LINK causes LE to create a new enclave, or representation of the unit, which can be expensive in terms of processor use, especially for languages like C++ with complicated runtime environments. The same is true for enclave termination when the target program returns.
Native program calls have several advantages. They look nicer in the source code. The call is independent of the underlying environment. In CICS' case, the call turns into a CICS LOAD followed by a branch. Additionally, environmentally neutral modules without CICS commands will execute just as easily in batch or online.
When done correctly, these calls avoid enclave creation and the associated overhead that can bog down mainframe performance.
Native calls versus thread safety
Thread safety's performance benefits come from avoiding the switch between the QR and open TCBs. Selecting a TCB depends on CICS' knowledge of the currently running module's attributes in the program's definition.
CICS uses LINK and transfer control (XCTL) commands to keep track of a transaction's current program. However, native language calls, which do not use LINK or XCTL, effectively short-circuit the tracking mechanism because CICS can't assume a loaded module actually executed.
For example, a transaction begins with PROGA, which is defined as THREADSAFE. It makes a DB2 call, so CICS switches and keeps the task on an open TCB. PROGA connects via LINK to PROGB, which is not thread safe. CICS thus switches to the QR task before passing control to it. PROGB subsequently calls PROGC, which is thread safe. Now PROGC makes a DB2 call that forces a switch to an open TCB. Upon return from DB2, CICS checks the concurrency value of the last program it knows about, PROGB. PROGB is quasi-reentrant, so CICS will bounce the transaction back to the QR TCB despite PROGC's CONCURRENCY attribute.
Along with the potential mainframe performance hit, this misinformation can cause logic problems. For instance, if PROGA called PROGB instead of using LINK, CICS would assume the second program was thread safe based on the first module's definition. As a result, bad actions might occur depending on how far PROGB is from thread safety and reentrancy standards.
Note to readers:
Throughout this tip, the author uses "task" and the control block that represents the task, "TCB," interchangeably. "L8" also represents the different types of open tasks that CICS maintains.
What mainframe programmers can do
Some installations may LINK or XCTL between programs to get the maximum benefit from thread safety and avoid potential reentrancy problems. Others may use native language calls to avoid the expense of LE enclave initialization and termination.
If the answer is somewhere in between, you could try to 'fool' CICS by LINKing to a thread-safe program before calling the rest of the application modules. This may keep the transaction on an open TCB, although, given how dynamic and complicated applications can be, the number of avoided switches will be unpredictable. It will also not guard against the odd quasi-reentrant program that may blow up in a multi-threaded environment.
Anyone interested in this issue should take traces of their online applications and examine CICS monitoring facility records for TCB switches. The answers may surprise and depress you.
Use CICS enqueue for thread-safe programming
Mobile at the forefront with CICS Transaction Server 5.2
Mainframes offer ultimate security? Maybe not