The Evolution of CICS: CICS - State of the Art (1984)

Preface: With each new version and release of the Customer Information Control System (CICS), the product introduced support of new or improved technologies. When reviewing the evolution of CICS, one has to remember the date of the product enhancement, and then consider the nature of the enhancement and why it was important at the time. This article examines the CICS "State of the Art" relevant in 1984.

In most cases, software products with long life cycles usually go through periods of change. Not just the incorporation of newer technologies, but perhaps the discontinuance of previous support now superseded by later product enhancements. Such was the case with CICS in 1984.

In terms of new support, CICS synchronized its support of Intersystem Communication (ISC) and Multi-Region Operation (MRO) with CICS/VS 1.6.1. ISC support of "function shipping" became available with CICS/VS 1.4 and MRO support of both "transaction routing" and "function shipping" became available with CICS/VS 1.5. CICS/VS 1.6.1 added transaction routing, now making the two functions available between CICS systems on one or more machines.

ISC and MRO enabled users to derive multiple benefits. Data and workloads could be distributed across multiple regions and machines. Multi-processors were better utilized. System availability was improved because the failure of one system did not prevent other CICS regions from continuing to operate. Virtual storage constraints were reduced or eliminated because the workload could be distributed across multiple environments. There were and continue to be many advantages due to the functions which have evolved with CICS.

In addition to ISC transaction routing now being supported, IBM issues other statements of direction regarding CICS support. Older functions that were now superseded by new and improved functions were announced for discontinuance. The list of functions to be discontinued included support for PAII macro imbedded in CICS code, static user exits, VSAM ICIP, segmented records and indirect access.

With the advent of global user exits in CICS management modules, it was no longer necessary for users to reassemble the management module in order to add exit programming. Exit code could now be activated dynamically. This architectural change obviated the need for CICS to continue supporting static exits.

Prior to the improved CICS exit architecture, certain IBM and/or vendor products found it necessary to place "hooks" within CICS code which would then execute the subject code. Performance Analyzer II was one such product. User and vendor modification of CICS code has always been a source of runtime errors, causing CICS not to execute correctly. CICS wanted to accommodate users exits and the new exit architecture provided ample exit points and much improved system integrity.

In 1984 VS COBOL II was announced and this had significant value to CICS and CICS users. Historically, most CICS users program using COBOL. With the initial CICS support of COBOL in 1970, CICS found it necessary to modify the runtime use of COBOL programs, making unique copies of COBOL control blocks (Task Global Table (TGT) and Program Global Table (PGT)) for each task concurrently using a given COBOL program. This scheme worked fine but it did mean a CICS dependency on COBOL internals. This scheme could now be abandoned because the VS COBOL II compiler provided for concurrency (multiple instances of the same program). 1970 to 1984? Patience rewarded.

The evolution of CICS continued in 1984. Not with major releases such as 1.3, 1.4, 1.5 or 1.6, but improvements in any case. CICS was earning its reputation of being a robust, timely and leading-edge product.

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