Enhanced Open Transaction Environment (OTE)
An integrated enterprise, one where all the resources and expertise of the organization can be quickly brought to bear on evolving market opportunities, puts enormous demands on an information system. In their attempts to create Enterprise Computing systems, businesses have moved from single-processor servers to Symmetric Multiprocessor (SMP) servers and more recently, to multiple SMPs. Now more and more companies are taking the next step and clustering these servers.
A cluster consists of interconnected SMPs utilized as a single, unified computing resource. The most effective form of clustering is the single-system image cluster, where all the servers appear to client applications as a single system. In this "shared data" (as opposed to "shared nothing") approach, every server has access to all the data, and any transaction can run on any server. Workload balancing can ensure an even distribution of work. CICS introduced the concept of Open Transaction Environment to exploit this technology.
Prior to OTE, all application code runs under the main CICS® TCB called the Quasi-reentrant (QR) TCB. The CICS dispatcher sub-dispatches the use of the QR TCB between the CICS tasks. Each task voluntarily gives up control when it issues a CICS service which then issues a CICS dispatcher wait. There is only ever one CICS task active at any one time on the QR TCB.
Programs are said to be quasi-reentrant programs because they take advantage of the behaviour of the CICS dispatcher and the QR TCB - in particular there is only ever one CICS task active under the QR TCB. This means although the same program can be being executed by multiple CICS tasks, only one of those CICS tasks is active at any given point in time. Contrast this with the situation whereby multiple instances of the same program are executing each under a separate TCB. In this scenario, multiple tasks would be active in the same program at the same time and the program would have to be fully MVS reentrant at the very least. For a program to be threadsafe, it must go beyond being fully reentrant and use appropriate serialization techniques when accessing shared resources.
Quasi-reentrant programs always run under the QR TCB and can access shared resources such as the Common Work Area (CWA) or shared storage obtained via EXEC CICS GETMAIN SHARED safe in the knowledge they are the only CICS user task running at that instance. This is because running under the QR TCB guarantees serialized access to those resources. An example would be a program which updates a counter in the CWA. The program is sure to be alone to update this counter and when it stops or gets suspended by the CICS dispatcher, it is sure to know the counter still has the value it assigned.
OTE introduces a new class of TCB called an open TCB, which can be used by threadsafe applications. An open TCB is characterized by the fact it is assigned to a CICS task for the life of the CICS task and multiple OTE TCBs may run concurrently in CICS. A threadsafe application is defined as a program which uses appropriate serialization techniques, such as compare and swap or enqueue, when accessing any shared resource(s). It must be capable of running concurrently on multiple TCBs, and must not rely on quasi-reentrancy to serialize access to shared resources and storage.
There is no sub-dispatching of other CICS tasks under the open TCB. An application executing under an open TCB can issue non CICS API requests which may involve the TCB being blocked. Blocking is allowed because only this TCB is halted, and not the whole of CICS, which is what happens if a blocking request is issued under the QR TCB. Examples of non CICS APIs would be MVS services such as GETMAIN and MVS UNIX® System Services POSIX functions. In CICS TS 2.2 we added support that enabled CICS/DB2 applications to run in an OTE. Previous to this they had to switch TCB when issuing DB2 requests. With OTE they benefited from reduced TCB switching which improved their performance. Existing or new CICS DB2 applications written in any language which access DB2 Version 6 or later now had the opportunity to gain the performance benefits provided by OTE.
In CICS TS V3.1 we have introduced the ability for an application to define itself as having to run on its own open TCB, whether it is a CICS/DB2 application or not. This extends the use of OTE by providing support for COBOL, PL/I, Assembler, and non-XPLink C/C++ OPENAPI application programs. The program will run on its own TCB from start. However, OPENAPI requires the application to be coded to threadsafe standards. Use of any non-threadsafe CICS commands will cause a switch to the QR TCB, then CICS will switch back to the OTE TCB before returning control to the program.
Recognising this, all EXEC CICS Web API commands have been made threadsafe. These commands include WEB READ, WEB WRITE, WEB SEND, WEB RECEIVE, WEB RETRIEVE, WEB STARTBROWSE, WEB READNEXT, WEB ENDBROWSE, WEB EXTRACT, EXTRACT WEB, EXTRACT TCPIP and EXTRACT CERTIFICATE. This removes the requirement for CICS Transaction Server to return to the QR TCB to run these commands. As a result, applications (both Java and non-Java) that use these commands should be able to obtain the performance improvements resulting from reduced TCB switching. Also threadsafe are the new Web API commands that support outbound HTTP, such as WEB OPEN, WEB CLOSE, WEB CONVERSE and WEB PARSE URL.
This removed a major bottle neck in the application throughput running under CICS.
Further information on OTE can be found in the Redbook 'Threadsafe Considerations for CICS' SG24 6351