CICS/DLI systems programmers, secure in the knowledge they could safely ignore the CICS Open Transaction Environment (OTE), have had a rude awakening. With the implementation of support for threadsafe Database Control (DBCTL) under CICS TS 4.2, IBM has brought the benefits (and risks) of OTE to the CICS/DLI community.

Until now, CICS/DLI customers could avoid the challenges of running with a threadsafe Database Management System (DBMS). Threadsafe had originally been introduced to the CICS world as a way to reduce CPU utilization in CICS/DB2 transactions; the CPU savings were large enough to mask the significance of the OTE as a major architectural shift in how CICS functions. Over the past few years, however, IBM has converted other CICS products to use Open Task Control Blocks (TCBs) in place of special purpose TCBs, continuing to shift additional workload to the open environment. For example, since the introduction of the OTE, IBM has announced OPENAPI support for several CICS subproducts, including WebSphere MQ and CICS Sockets. The addition of CICS/DLI to the list shows once again that IBM is serious about moving workload to the open environment.

This article introduces the CICS OTE and the concepts, benefits and potential hazards of threadsafe to the CICS/DLI systems and applications programmer.

Historical Perspective

To understand OTE, a brief history lesson will help. There will be several references to DB2 because the history of OTE is bound tightly to DB2.

When CICS was first released, it was designed to run as a single MVS TCB. When the CICS dispatcher gave control to a user program, that program had complete control of the region until it requested a CICS service; if the program called a service that included an Operating System (OS) wait, the entire region would wait with it. The CICS programming guides included a list of OS and COBOL commands that might issue these waits and couldn’t be used by CICS programs. The flipside of these limitations was the concept of “pseudo-reentrancy,” meaning CICS programs didn’t have to be reentrant between CICS commands.

With all the activity in a CICS region being single-threaded, it was restricted to the capacity of one CPU. IBM’s move toward multi-processor mainframes brought new issues for the CICS systems staff, as the purchase of a “faster” mainframe would result in a slowdown of CICS if the individual processors on the new machine were slower. IBM tried to offload some CICS workload to additional CICS-controlled MVS TCBs that would be able to run concurrently on a multi-processing machine. For convenience, IBM labeled the main CICS TCB as the Quasi-Reentrant (QR) TCB.

The first meaningful CPU offloading came with the introduction of the DB2 DBMS. Rather than establishing one TCB for all DB2 activity, CICS created a separate TCB for each concurrent DB2 request and switched the task to that TCB while the DB2 system code ran. Although all the application code still ran single-threaded, each task's DB2 workload could be running simultaneously, limited only by the total capacity of a multi-processor. An unfortunate side effect of this design was that the processor overhead of all these TCB swaps (two for each DB2 request) added as much as 30 percent to an application’s CPU requirement.

Someone at IBM realized this TCB swapping overhead could be eliminated by simply not returning the transaction to the QR TCB and allowing application code to run on the DB2 TCB. To provide support for running CICS application code outside the QR TCB, the concept of the OTE was developed. The OTE lets an individual CICS transaction run under its own MVS TCB instead of sharing the QR TCB. Many transactions, each under their own Open TCB, can run at the same time in the same CICS region. In CICS TS 2.2, these DB2 TCBs (the L8 TCBs) were enhanced to run as OTE TCBs (note that the OTE also uses L9 TCBs, but this article is only concerned with L8s). CICS/DB2 transactions that remain on their L8 TCB when running application code would see a significant reduction in CPU utilization. Threadsafe CICS/DB2 programs require less CPU because they’re doing less work; fewer TCB switches require less processor capacity.

These CPU savings, unfortunately, come with a cost. The downside of the OTE is that more than one occurrence of the same program can run simultaneously, meaning CICS programs must now be truly reentrant between CICS calls, rather than just “pseudo reentrant.” A simple example of the type of problem created is the common practice of maintaining a record counter in the Common Work Area (CWA) that’s used to create a unique key. Running under the QR TCB, the integrity of the counter was assured as long as the record counter was updated before the next CICS command was issued. With the OTE, it’s possible for two or more transactions to use the counter simultaneously, resulting in duplicate keys.

2 Pages