Open TCB

Originally, CICS applications operated in a restricted, or closed, environment. Although the

applications could use the functionally-rich CICS application program interface (API), direct
invocation of other services was not supported. This is because CICS ran all user
transactions under a single z/OS TCB, the CICS quasi-reentrant (QR) TCB.

The open transaction environment is an environment where CICS application code can use
non-CICS services (facilities outside the scope of the CICS API) within the CICS address
space, without interference with other transactions. Applications that exploit the open
transaction environment run on their own open TCB, rather than on the QR TCB. Unlike the
QR TCB, CICS does not perform sub-dispatching on an open TCB. If the application running
on an open TCB invokes a non-CICS service which blocks the TCB, the TCB blocking does
not affect other CICS tasks.

The open TCBs that are used in the open transaction environment are managed in separate
pools, with each pool containing a different type, or mode, of open TCB. Each mode has a
specific purpose, and is handled by CICS in a different way. For example, J8 mode TCBs and
J9 mode TCBs are used to run Java programs under a Java Virtual Machine (JVM). The JVM is
created on the TCB. J8 TCBs are used for JVMs when the Java programs are defined as
executing in CICS key, and J9 mode TCBs are used for JVMs when the Java programs are
defined as executing in user key and storage protection is active. The CICS DB2 attachment
facility uses L8 TCBs for DB2 request processing.

The first benefit of the open transaction environment was that Java programs could run under
CICS, either as hot-pooled Java program objects or in a JVM.

Performance benefits can be gained because open TCBs, unlike the QR TCB or subtask
thread TCBs, may be used for both non-CICS API requests (including requests to DB2) and
application code. Because application code can be executed on the open TCB, the application
should not need to switch between different TCBs several times during the execution of a
CICS DB2 application. Before the open transaction environment was available, CICS used the
QR TCB for the CICS DB2 task-related user exit and for the application program's code.
Subtask thread TCBs were used for requests to DB2, and switching between the subtask TCB
and the QR TCB took place for every DB2 request. With the open transaction environment, the
same TCB can be used by the CICS DB2 task-related user exit, the SQL requests that CICS
makes to DB2, and any subsequent application code. The most important condition to be met
to achieve this is that the user application program, the EXEC CICS commands used in the
application, and any user exit programs involved with the application program, must be
threadsafe. Only code that has been identified as threadsafe is permitted to execute on open
TCBs.

Where the correct conditions are met, the use of open TCBs for CICS DB2 applications
decreases usage of the QR TCB, and avoids TCB switching. An ideal CICS DB2 application
program for the open transaction environment is a threadsafe program, containing only
threadsafe EXEC CICS commands, and using only threadsafe user exit programs. An
application like this will move to an L8 TCB when it makes its first SQL request, and then
continue to run on the L8 TCB through any amount of DB2 requests and application code,
requiring no TCB switching.