Perhaps the most significant enhancement in the CICS TS product was the introduction of CICS support and use for the new MVS Logger. Prior to CICS TS, CICS Journal Control was widely used since the 1970s for the purpose of logging the activities of recoverable units of work and for the recording of user journals (audit trails, forward recovery information, etc). During the 1980s, Journal Control was enhanced a number of times but during the 1990s it became evident that either Journal Control would have to be significantly reworked or a suitable replacement found. The new MVS Logger addressed most of the concerns and requirements which had developed for CICS Journal Control.
With CICS Journal Control, most users had two log data sets; Log A and Log B. When one data set filled, a switch was made to the other data set. Unfortunately, there was no protection against CICS overwriting data in the new data set which might have contained data still needed for in-flight units of work. If emergency restart were required, CICS could not correctly backout in-flight work resulting in a data integrity exposure.
CICS emergency restart prior to CICS TS may have taken considerable time for larger users. CICS had to scan both log data sets looking for data that pertained to in-flight units of work. These and other user requirements dictated a need for CICS Development to improve the function of logging and journalling. CICS was one of the early adopters of the new MVS Logger.
Use of the new MVS Logger was not an option with CICS TS. Not only was the new software required but also the Logger required a coupling facility, either the hardware or an emulation of the hardware running in an MVS LPAR. CICS provided utilities for estimating coupling facility storage requirements and for reading old or new log data formats in the event data recovery was needed.
It took most CICS users a considerable amount of time to learn about the MVS Logger and its use of the coupling facility technology. And putting service aside (software maintenance), it took time to implement the new support and then tune it to the nature of the user's workload. Many presentations were given and documents written to assist the user in making the transition from the use of Journal Control to the use of the MVS Logger.
But once implemented, the benefits became apparent. Emergency restart was faster, less storage was needed for log data, archiving was provided, no data overwriting occured, etc. A new requirement arose, however, where some users objected to the coupling facility requirement and requested that the MVS Logger support logging to direct access storage devices (DASD). That requirement would be satisfied with DASD Logging support in a later release of CICS TS (1.2).
The focus on logging may have detracted from the many other product enhancements in CICS TS. Most CICS users were long time users of VSAM and there was a strong requirement for better data sharing facilities. CICS provided function shipping of VSAM requests to a so-called file owning region (FOR) but users felt this introduced additional processor overhead and failure of the FOR was considered a single point of failure. CICS Development was in an awkward position, since it did not own the VSAM code and help in resolving this user requirement would have to come from VSAM Development.
CICS TS announced support for VSAM Record Level Sharing (RLS) in which CICS would provide for logging, backout and restart involving shared VSAM files, and VSAM provided sharing at the record level. RLS enabled two or more CICS systems on one or more MVS images to share data with integrity. A coupling facility was required in order to provide sysplex-wide enqueueing on data. Performance was improved because enqueues now were at the record level rather than the control interval level.
The new Logger and RLS support were complementary to CICS' support of parallel systems. Increasingly, more and more users were interested in high availability configurations and increased overall system thruput. CICS added still more support in this regard with implementation of VTAM Generic Resources (VTAM GR).
To avoid having single points of failure, the user might clone (duplicate) terminal and application owning regions (TORs, AORs), such that a failure of one region or machine would not prevent end users from performing their application functions. With support of VTAM GR, users no longer logged onto specific CICS region APPLIDs but rather to a generic name. Multiple TORs, each with their specific APPLIDs could be members of a generic group, for instance "CICS". Users could now be connected to an eligible TOR and have their work routed to eligible AORs, avoiding any regions which may currently be unavailable.
Support for the new MVS Logger, VSAM RLS and VTAM Generic Resources were but a few of the enhancements in CICS TS Version 1. The Internet support added to CICS with CICS/ESA 4.1 was further enhanced. A new CICS Recovery Manager (domain) was added to the product, further improving data integrity for local and distributed processing. The CICS System Manager (CICSPlex) which was originally introduced as a separately orderable fee product was now integrated into the CICS TS base product.
When CICSPlex was initially available many users were interested however given the business economy at the time, users may have been budget constrained and therefore did not order CICSPlex. With the integration of CICSPlex into the base CICS TS product, usage was slow to be implemented but in more recent years users have discovered the comprehensive nature of the product and its ability to help manage large complexes.
CICS TS Version 1 established the base for future enhancements to CICS, such as more comprehensive support of the Internet and support of object oriented systems, including the use of Java and Enterprise Java Beans (EJB).
Copyright © 2004 - Yelavich Consulting, Sparks, NV
Click here
for other articles regarding the evolution of CICS.