There are several different open TCB types, depending on the type of processing occurring. Although the J-series of open TCBs is used to run Java programs, this article is only interested in the L-series.
The L type open TCB evolved from the DB2-specific TCB CICS used to offload DB2 processing from the QR TCB. Each CICS transaction accessing DB2 would have one of these TCBs assigned to it. When the application program issued a DB2 call, CICS would spin the task over to its assigned DB2 TCB to run the DB2 system code, then spin it back to the QR TCB when DB2 system processing completed. A complex CICS/DB2 transaction could issue several thousand DB2 calls, resulting in twice as many TCB spins, which added up to a significant amount of CPU time spent swapping TCBs. IBM realized that the number of TCB swaps required could be significantly reduced if the application could simply remain on the DB2 TCB after DB2 processing was completed. The open TCB is the result.
As first introduced, the open TCBs were named L8 TCBs and were accessed by calling a CICS Task Related User Exit (TRUE) initialized with the OPENAPI parameter. Although the “8” refers to the CICS system storage key 8, tasks defined as user key (key 9) remain in user key when running on an L8 TCB.
IBM later enhanced open TCB access by allowing application programs to be defined as OPENAPI. Any program defined as OPENAPI will be initialized on an L-series TCB, and all application code is guaranteed to run on the instance of the L-series TCB on which the program was initialized. Programs defined as OPENAPI and running in USER key will run on an L9 TCB; CICS key programs will run on an L8 TCB.
Accessing the OTE
There are two methods to run application code in the OTE: Define an OPENAPI TRUE and create a TRUE program and stub, or modify the program’s API attribute in its RDO PROGRAM definition to OPENAPI.
You can define an OPENAPI TRUE and create a TRUE program and stub. Because it’s the CALL itself that results in a switch to the L8 TCB, the TRUE program need not actually have any code associated with it other than a BR 14 (see Figure 1). If a program that’s defined as threadsafe issues a call to the OPENAPI TRUE, CICS will move it to an L8 TCB, and it will remain on that L8 TCB until the program either terminates or issues a non-threadsafe EXEC CICS command. Not all EXEC CICS commands are threadsafe. Consult the Application or Systems Programming Guide for a list of commands that are threadsafe in your release.
If a program has some code that should run in the open environment, and some that must run on the QR TCB (e.g., for serialization purposes), a second dummy TRUE can be established that’s initialized without the OPENAPI parm. A call to the non-OPENAPI TRUE will cause CICS to move the task to the QR TCB. In this way, the programmer can control which environment the task is in at any point in processing.
Unfortunately, there’s no way to tell at run-time if your task is currently running on an open TCB. In a complex program, the programmer may not be able to tell what the state of the program will be at a specific paragraph; he would have to issue “just in case” TRUE calls to ensure the proper processing environment.