CICS OPENAPI TRUEs, such as those for DB2 and WebSphere MQ, must execute under an Open TCB. Upon return to the application after the call to the TRUE, CICS will leave control on the Open TCB if the application is defined as threadsafe, or switch back to the QR TCB if it’s defined as quasirent. If the program is threadsafe, control will remain on the Open TCB until a non-threadsafe EXEC CICS command is issued. CICS will then switch to the QR TCB to process the command.

In CICS Transaction Server 3.1, programs defined with API(CICSAPI) are invoked under their Open TCB. Like JVMs, their internal logic must run under an Open TCB. If they invoke threadsafe EXEC CICS commands, these are processed under the Open TCB. If they invoke non-threadsafe EXEC CICS commands, CICS will switch control to the QR TCB for the duration of the command, and then switch back to the Open TCB when the command completes.

CALLed Programs and Non-Serialized Resources

Switching an application program definition to make it threadsafe doesn’t guarantee that the program itself is written to threadsafe standards. All it means is that CICS can execute the program under an Open TCB if it deems it appropriate to do so. Whether the program can actually run under such a TCB is another matter. If it wasn’t written to threadsafe standards, various unpredictable results may occur. The easiest to identify is a simple abend. Such programs may not always result in abends; they may leave the data associated with the programs in an invalid state. This result is hard to detect and even harder to resolve.

One example where problems can occur is when a program that’s indeed threadsafe is redefined as such to CICS. However, the program makes use of calls to a subprogram. If this was, for example, a subprogram invoked from a static COBOL CALL, this would be link-edited to the main program. Natural language calls such as this aren’t part of the EXEC CICS Application Program Interface (API); they don’t cause CICS to pass through its program domain logic. At the program level, CICS is unaware that the main program has passed control from itself to somewhere else. The program domain still believes the main program is in control.

If the subprogram wasn’t written to threadsafe standards, it wouldn’t be able to safely execute in a multi-threaded TCB environment. For example, it may have a hard-coded Register Save Area  (RSA) within itself. While this is a safe technique to use if CICS guaranteed to execute only the subprogram in a serialized, uninterrupted manner under the QR TCB, it’s not viable if multiple TCBs can simultaneously enter the subprogram. The RSA contents won’t be guaranteed to be preserved across each call to the program, and an abend or program check is the likely result.

This type of problem could be detected if the load module containing the programs had been link-edited with the RENT attribute since a self-modifying subprogram such as this would have abended trying to update its read-only storage. This could be avoided if a CICS API command such as an EXEC CICS LINK was used to pass control to the subprogram. CICS would then have a program definition for the subprogram, and this could have been defined as quasirent and ensured that the LINKed to program was executed under the serialized QR TCB environment. EXEC CICS LINK commands may not always be appropriate, however.

A natural language call has a shorter path length than a LINK; the trade-off is that it doesn’t provide the rich options available from an EXEC CICS LINK command such as workload balancing, trace diagnostics, Execution Diagnostic Facility (EDF) hooks, etc. If a natural language call was still required, another alternative would be to rewrite the subprogram to threadsafe standards, such as giving it its own separate working storage area (DFHEISTG for assembler programs, for example). Each transaction would then get its own copy of user storage mapped to DFHEISTG, and the RSA contents would be separated between transactions and not potentially trampled on.

Non-serialized programs can lead to problems such as this. They may be made threadsafe by various techniques. If they require serialization around specific operations within them, they can employ techniques such as the use of EXEC CICS ENQUEUE and DEQUEUE commands, or instructions such as Compare and Swap (CS), Compare and Double Swap (CDS), Test and Set (TS), or even the Perform Locked Operation (PLO) instruction.

Shared Storage Use

5 Pages