What is the open transaction environment and how can I benefit from it?

The open transaction environment (OTE) function was added to CICS® Transaction Server for OS/390®, Version 1 Release 3 and later versions.

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, 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. For example, some services provided by DB2®, MVS, UNIX System Services, or TCP/IP, might result in TCB blocking.

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:

J8 mode TCBs and J9 mode TCBs
Open TCBs that 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 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.
Start of changeL8 mode TCBs and L9 mode TCBsEnd of change
Start of changeare both used to run OPENAPI programs, that is those defined as OPENAPI by their PROGRAM resource definition.

The MAXOPENTCBS system initialization parameter controls the number of L8 and L9 TCBs in the OPEN TCB pool.

End of change
L8 mode TCBs
are Start of change also End of change used when programs need access to a resource manager through a task-related user exit (TRUE) enabled using the OPENAPI option on the ENABLE PROGRAM command.

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.

L8 mode TCBs
are also used by CICS itself, because CICS uses OPENAPI CICSKEY programs which run on L8 TCBs:
Start of changeX8 mode TCBs and X9 mode TCBsEnd of change
Start of changeare both used to run C and C++ programs compiled with the XPLINK option. X8 TCBs are used for programs in CICS key, and X9 mode TCBs are used for programs in user key. Each instance of an XPLink program uses one X8 or X9 TCB. in the CICS Application Programming Guide has more information about using XPLink.End of change

"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.

Note:
All references to DB2 assume that you are using one of the currently supported versions of DB2. At the time of publishing these are Versions 7, 8 and 9. There are differences for versions prior to Version 6, and if you are attempting to work with any such unsupported combination, you should read the relevant information from earlier CICS publications.

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:

  1. CICS must be connected to DB2 Version 6 or later. "Migrating to a different release of DB2" in the CICS DB2 Guide has full details of the CICS DB2 configuration needed to support the open transaction environment, including APARs that must be applied for DB2 and for CICS.
  2. The system initialization parameter FORCEQR must not be set to YES. FORCEQR forces programs defined as threadsafe to run on the QR TCB, and it might be set to YES as a temporary measure while problems connected with threadsafe-defined programs are investigated and resolved.
  3. The CICS DB2 application must have threadsafe application logic (that is, the native language code in between the EXEC CICS commands must be threadsafe), use only threadsafe EXEC CICS commands, and be defined to CICS as threadsafe. It must use only threadsafe dynamic plan exits, task-related user exits and global user exits. Only code that has been identified as threadsafe is permitted to execute on open TCBs. If your CICS DB2 application is not defined as threadsafe, or if it uses EXEC CICS commands or exits which are not threadsafe, TCB switching will take place and some or all of the performance benefits of OTE exploitation will be lost. How can I make my applications exploit the open transaction environment? discusses all these requirements in more detail.

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 ]]