• CICS Transaction Server 3.1 extended OTE to provide L8 and L9 Open TCBs for CICS-key and user-key application programs defined with OPENAPI on their program definitions. In addition, X8 and X9 TCBs were introduced for support of XPLINK in C and C++ CICS-key and user-key applications. Internally, CICS Transaction Server 3.1 also exploits S8 Open TCBs for CICS Sockets domain work, and uses L8 TCBs for CICS programs defined as OPENAPI and which must perform Web Services activity that references data on the Hierarchical File System (HFS). Such calls would block the QR TCB if executed under that. They’re a good example of CICS using its own OTE functionality to exploit multiple TCBs for its own purposes. CICS Transaction Server 3.1 also removed support for H8 TCBs.
• CICS Transaction Server 3.2 has further extended support for OTE by enabling the CICS to WebSphere MQ adaptor as an OPENAPI-enabled TRUE, as CICS Transaction Server 2.2 did for the DB2 TRUE. It also enabled parts of the EXEC CICS File Control component to exploit OTE, too. These enhancements will help CICS execute parallel workloads on multiple TCBs.
There’s a performance cost in switching between TCBs. The more often CICS has to issue a TCB switch to move control from the QR TCB to an L8 TCB, for example, and back again, the more CPU usage is required.
So it’s best to reduce TCB switching as much as possible. This means programs need to be correctly defined to CICS. For example, Global User Exits (GLUEs) executed in the path of threadsafe application logic should be made threadsafe, if possible, to avoid the need for CICS to have to switch to the QR TCB when driving them. GLUEs driven in threadsafe commands may issue EXEC CICS commands that are themselves non-threadsafe, and so require switching back and forth from the QR TCB to process them. The same applies to threadsafe application programs that issue non-threadsafe EXEC CICS commands.
It’s important to correctly define programs, especially exit programs, to avoid unnecessary TCB switching. It’s also important to understand the sequence of EXEC CICS commands issued from within the applications and to recognize those commands that require TCB switching.
CICS Application Threadsafety CICS application program definitions or program autoinstalls let the programmer define whether an application is threadsafe. A definition of CONCURRENCY(THREADSAFE) means a program was written to threadsafe standards. If it accesses any shared resources such as the CICS Work Area (CWA), it takes into account the possibility that other programs may be executing concurrently and attempting to modify the same resources.
A program that isn’t threadsafe is defined as CONCURRENCY (QUASIRENT). Such a program is quasi-reentrant only, and relies on CICS to provide serialization when it executes. CICS dispatches such programs under the QR TCB, so this provides such serialization by dispatching only a single instance of the programs at any time.
The threadsafety of a CICS application applies to its own logic, not to the particular EXEC CICS commands the program may issue. Some EXEC CICS commands are threadsafe, and don’t have an affinity to any particular TCB type. Other EXEC CICS commands aren’t threadsafe, and CICS will automatically switch to the QR TCB to process them. Defining an application as threadsafe means the business logic of the program is itself able to execute under an Open TCB.
JVM programs must execute under their Open TCB in CICS. While the thread of execution is in JVM, the code is executing under a J8 or J9 TCB. If the Java application invokes a JCICS method call, then CICS will invoke the appropriate EXEC CICS command mapped to that method. If this is a threadsafe EXEC CICS command, it will execute under the Open TCB. If it’s not threadsafe, CICS will switch control to the QR TCB for the duration of the request, and then switch back to the JVM’s Open TCB when control returns from CICS.