IBM’s CICS transaction processing software has been enhanced in recent releases to extend its support for the Open Transaction Environment (OTE). This article describes the background and history of OTE, and offers some examples and guidance on several problems that may be encountered when exploiting OTE. This article also describes how to prepare your CICS systems and applications to efficiently exploit OTE.  

Evolution of OTE

Support for OTE was first introduced in CICS Transaction Server 1.3. Initially, this support was limited to the Java programming environment within CICS, which also was introduced in this release. OTE provides a means to execute different programming environments such as a Java Virtual Machine (JVM) under a separate z/OS Task Control Block (TCB). Conversely, traditional CICS workloads execute in a single-threaded manner under the CICS Quasi-Reentrant (QR) TCB. This is the workhorse TCB that has handled all the CICS application workload in previous releases.

The CICS Dispatcher domain employs rapid multi-tasking, giving each task running under the QR TCB the chance to execute until it cooperatively relinquishes control once more (for example, as the result of a suspend or wait). This cooperative processing model is efficient at rapidly dispatching work in CICS. However, exploiting a single TCB to dispatch its application work means CICS is singlethreaded and can’t exploit multiple Central Processors (CPs) in a truly concurrent manner.

OTE-managed TCBs are called Open TCBs in CICS. They’re truly independent of the QR TCB and are dispatched and executed separately. In a multiengine hardware environment, with multiple CPs available for parallel execution of work, Open TCBs can execute code at the same time the QR TCB runs other work in the same CICS region.

Provision of separate TCBs to execute work in parallel in CICS helps address any throughput constraints that might be seen when all work is otherwise executed under the one (QR) TCB. In addition, the use of z/OS services that can suspend a TCB and which would block the QR TCB for a period of time can now be considered in CICS. Previously, these services were documented as being restricted for CICS application programming use. With OTE, and in particular the latest CICS Transaction Server V3 enhancements for OPENAPI programming, such calls may now be considered for use in CICS. This is feasible, since any effect of blocking a particular application executing code under its own Open TCB won’t affect other applications also running under their own TCBs in the same CICS system.

The evolving history of OTE in CICS can be summarized as follows:

• CICS Transaction Server 1.3 introduced OTE in CICS. Support was limited to Java applications. JVMs were executed under J8 Open TCBs. In addition, H8 Open TCBs were provided to execute an optimized Java environment. This was known as Hotpooling, and provided a compiled Java run-time environment for CICS applications. It was introduced as a temporary measure; the JVM runtime environment was acknowledged as the strategic platform for Java applications in CICS.

• CICS Transaction Server 2.2 extended OTE to also support Task Related User Exits (TRUEs) defined as OPENAPI. The DB2 TRUE was changed to exploit this. Such TRUEs were invoked under L8 Open TCBs.

• CICS Transaction Server 2.3 provided various enhancements to OTE functionality, such as user-key (J9) Open TCBs for JVMs.

5 Pages