Before CICS® Transaction Server for OS/390®, Version 1 Release 3, user applications and exits 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, known as the CICS quasi-reentrant (QR) TCB. Direct invocation of other services outside the scope of the CICS permitted interfaces could interfere with the use by CICS of the QR TCB. In particular, requests resulting in the suspension ("blocking") of the QR TCB, which happens when an MVS™ wait is issued, would cause all CICS tasks to wait.
The open transaction environment (OTE) function was added to CICS Transaction Server for OS/390, Version 1 Release 3 and later versions. 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. For example, some services provided by DB2®, MVS, UNIX System Services, or TCP/IP, might result in TCB blocking.
The open TCBs that are used in the open transaction environment are managed in separate pools, with each pool containing a different type, or operational mode, of open TCB. Each mode has a specific purpose, and is handled by CICS in a different way. The types, or modes, of open TCB are:
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 maximum number of these TCBs that CICS will create in the JVM pool is controlled by the MAXJVMTCBS system initialization parameter. "How CICS manages JVMs in the JVM pool" in Java Applications in CICS has more information about how CICS manages JVMs and their TCBs.The MAXOPENTCBS system initialization parameter controls the number of L8 and L9 TCBs in the OPEN TCB pool.
The CICS DB2 task-related user exit operates in OPENAPI mode (it is an open API TRUE). In this situation, the CICS DB2 attachment facility uses L8 TCBs for DB2 request processing. "Overview: How threads work" in the CICS DB2 Guide has more information about how CICS uses open TCBs as thread TCBs for the CICS DB2 attachment facility. "Enabling CICS DB2 applications to exploit the open transaction environment (OTE) through threadsafe programming" in the CICS DB2 Guide explains what your CICS DB2 application programs must do in order to gain performance benefits by continuing to run on the L8 mode TCB after the DB2 request has been completed.
"System initialization parameters for open TCBs" in the CICS System Definition Guide has more information about how CICS manages open TCBs, and about specifying the MAXJVMTCBS, MAXOPENTCBS and MAXXPTCBS system initialization parameters.
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. From CICS Transaction Server for z/OS, Version 2 Release 2, applications that involve a task-related user exit enabled using the OPENAPI option on the ENABLE PROGRAM command can also exploit the open transaction environment to provide performance benefits. Task-related user exits like this are known as open API TRUEs. An open API TRUE will be given control under an L8 mode open TCB, and can use non-CICS APIs without having to create, manage and switch between subtask TCBs. The CICS DB2 task-related user exit now operates as an open API TRUE . Existing or new CICS DB2 applications written in any language that access DB2 have the opportunity to gain the performance benefits provided by the open transaction environment.
These 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 L8 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. The next topic explains in detail what it means for an application to be threadsafe.
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. This situation produces a significant performance improvement where an application program issues multiple SQL calls. The gains are also significant when using an enterprise bean, because when enterprise beans make DB2 requests, they require additional TCB switches to and from the enterprise bean's own TCB. If the application program does not issue many SQL calls, the performance benefits might not be as significant.
In order to gain these performance benefits for CICS DB2 applications, you must meet the following conditions:
Additional information about how CICS DB2 applications use open TCBs can be found in "SQL, threadsafe and other programming considerations for CICS DB2 applications" in the CICS DB2 Guide
[[ Contents Previous Page | Next Page Index ]]