This series reviews the CICS Open Transaction Environment (OTE) and its effect on CICS and how CICS uses machine resources. The first article, “CICS and the Open Transaction Environment: A Retrospective,” (available at http://esmpubs.com/q98ug) examined the history of CICS and IBM’s attempts to provide relief from CICS’ chronic CPU constraint, culminating in the introduction of the OTE. This second article concentrates on the potential benefits of OTE to non-DB2 users, while the final article will focus on the potential CPU savings OTE can provide to CICS/DB2 applications.
When the CICS OTE was announced, it was viewed primarily as a way to reduce CPU utilization; the potential for up to a 40 percent reduction in CPU for large CICS/DB2 applications overshadowed anything else the OTE might provide. This savings only occurs if the programs in use are written to threadsafe standards and are allowed to run on an L8 Task Control Block (TCB) following an SQL call; the longer a program remains on its L8 TCB, the greater the CPU savings. (While the OTE includes several different TCB types, this article only discusses the L8 and L9 TCBs. Usually, there’s no functional difference between an L8 and an L9 TCB, so this article uses the term “L* TCB.” The qualified TCB type [L8 or L9] is used only when required to distinguish the differences between these types.)
However, as more programs spent a greater portion of their processing time on L8 TCBs, it became apparent that OTE exploitation had benefits beyond DB2 CPU savings. Here, we will discuss how the use of the OTE can reduce hardware costs, increase multiprocessor exploitation, eliminate bottlenecks and simplify your CICS Multi-Region Operation (MRO) complex, all without any reference to DB2. We will also cover threadsafe non-compliance errors and how to distinguish them from “normal” abends.
The Effect of OTE on CPU Constraint
CICS’ single-TCB architecture—the Quasi-Reentrant, or QR, TCB—has consistently tied large CICS users to high-capacity individual processors. An active CICS region would always perform better on a small capacity box with a single, fast processor than on a large capacity box with multiple, slower processors. As a region’s workload increased, the CPU requirement of the QR TCB would begin to approach the total capacity of a processor and performance would suffer; this condition, known as QR constraint, was to be avoided.
There are three ways to relieve QR constraint; however, all have negative consequences: reduce the workload, upgrade the CPU and offload work to another region.
To reduce workload, CICS has several tuning options available to throttle incoming transactions, smoothing out the normal short-term peaks and valleys of CPU utilization and preventing the region from bogging down. This has the unfortunate effect of increasing response times for all transactions and is only a temporary solution; eventually, there are no more valleys and response times become unacceptable.
While it’s a simple matter to suggest a CPU upgrade, financing it is a different story. Add the accompanying software costs and an upgrade quickly becomes a last resort. This is especially true if only CICS is constrained. It’s possible, theoretically, for CICS to be fully QR constrained on a triadic processor while the remaining processors are lightly used—leading to a situation where a machine is “maxed out” at less than 50 percent utilization.
Offloading work to another CICS region is the most commonly used option. A new CICS region, an Application Owning Region (AOR), is created and an application is removed from the existing region and installed in the new one. If there’s only one application in the constrained region, the region is “cloned,” the application is installed in both regions and a workload manager distributes the load between them. The resulting complex, called MRO, is used, to some degree, in most CICS shops. While MRO has benefits, its drawbacks include the additional overhead associated with:
• Adding a new CICS region
• Transaction routing
• CICS function shipping to share application resources
• Managing the complex.
When a transaction is executing in the OTE, it’s running under its own TCB, not the QR. A program executing on an L* TCB relieves QR constraint similarly to offloading to another CICS region, but without the drawbacks discussed earlier. If enough processing is moved into the OTE, QR constraint can be relieved to where existing AORs can be merged, eliminating the overhead of maintaining multiple regions and function shipping. The goal is to reduce QR processing requirements to where a single CICS region can fully occupy all the processors in a multiprocessor box before a hardware upgrade is required.