The Evolution of CICS: CICS and Multi-region Operation (1980)

CICS was introduced in the 1968-1969 time period, first as a Type II Application Program and then as a Class A Program Product. The 1970s saw widespread growth of CICS, both in terms of the number of customers using the product as well as growth within a customer's shop, with more usage of the product.

Prior to the rearchitecture of CICS and the delivery of the CICS/ESA product in the 1990s, CICS executed largely as a single operating systems task. Prior to the CICS/ESA product, CICS did implement some use of multiple operating systems task control blocks (TCBs) however the most popular way of achieving multiprocessor utilization came with the introduction of CICS' multi-region operation (MRO) support, announced in September 1979 and delivered in September 1980.

At the time MRO was introduced there was varied opinion as to why IBM chose to deliver that support at that time (1980). Some customers use of CICS had grown to such an extent that many encountered so-called virtual storage constraints in the late 1970s. IBM had not yet announced 31 bit addressing and extended virtual storage, so customers needed solutions within the 16 bit addressing limitation. MRO enabled such customers to utilize CICS MRO transaction routing and distribute their workload across multiple address spaces, and hence multiprocessors. This represented virtual storage constraint relief (VSCR) and better utilization of the multiprocessor (n-way engine).

But for those who thought MRO was justified by IBM soley on the basis of VSCR and MP utilization, missed other intended benefits of MRO. The user may wish to implement multiple application owning regions (AORs) so as to separate test and production, or to separate different applications or departments. If within the customer's shop, charge back systems were used, it was easier to associate computer usage by department or application, if they were separated from each other.

There was also the perceived differences in application execution. The user may have some applications that were heavy users of central processing unit (CPU) cycles and the user may have wanted to isolate those applications into their own region(s) and give preference to the high priority, faster units of work.

Some applications were felt to be more reliable than others. For instance as a new application went into production, until such time as it demonstrated stability, the user may have wanted to isolate that application rather than integrate it into a high volume production system (AOR).

Applications may have varied in their operational hours, such that by separating applications into groups with similar start/stop times, those applications could be better managed. Stopping some applications (AORs) might have other operational benefits such as freeing certain resources when the AOR was shutdown for the day. Other applications with longer operational hours were able to continue unaffected.

By the 1980s, customers were beginning to focus on high availability and included in that objective was the desire to avoid single point of failure. Through the use of MRO, the user might clone (duplicate) applications to run in multiple regions on one or more systems, such that the failure of one region did not prevent cloned applications from continuing to serve end users.

MRO is widely used and has provided multiple benefits to users. CICS continued to seek ways to increase multiprocessor utilization in the meantime. VSAM subtasking was introduced as a way of executing VSAM input/output under a separate MVS TCB. Open/Close, RACF, VTAM I/O and other functions were executed under separate operating systems dispatchable units of work (TCBs, SRBs, etc).

With the advent of the restructured CICS/ESA product, CICS introduced considerably more TCB usage, each designed to allow certain functions to execute concurrent with the main CICS TCB (the so-called Quasi-Reentrant (QR) TCB). With the advent of the CICS Transaction Server (TS) product in the late 1990s and early 2000s, CICS introduced the Open Transaction Environment (OTE) with which Java and DB2 work could be dispatched under different TCBs, increasing multiprocessor utilization. OTE for CICS DB2 became the first instance by which user applications could be dispatched under more than one MVS TCB without having to be pure reentrant.

Customer use of MRO continues, even with CICS changes to have greater concurrent use of MVS TCBs. It is expected that OTE will be enhanced to offer increased multiprocessing for a single workload.

Copyright © 2003 - Yelavich Consulting, Sparks, NV
Click here for other articles regarding the evolution of CICS.