z/OS and Friends: CICS Changing With the Times While Serving Longstanding Applications
Joe Gulla explains how the Customer Information Control System (CICS) relates to the programmer experience, and how it has evolved to handle growing workloads while embracing web services and new languages like Java
The Customer Information Control System (CICS) has a long history. You might say it exists in a world of the past, present and future as it embraces new paradigms as they evolve. It routinely extends itself through the addition of functional support.
This evolution and willful change will be an important part of this two-article series on CICS. Of course, the “old” CICS had a lot of evolution—anything but static. Same is true for the new(er) functions of CICS embracing Java, web services and SOAP technologies.
There in the Beginning
CICS is one of the early products from IBM that was written to support online data processing. Batch processing was well established in 1969, but real-time processing conventions were being defined by two IBM products—Information Management System (IMS) and CICS.
The CICS product was once called a teleprocessing (TP) monitor. Although that label understates the product’s functionality, some still use it today. A better label is middleware, which includes TP and many more functions that are built-in to CICS. The product is there, right in the middle between the OS and its hardware and the application. It is now distributed as a family of mixed-language application servers with substantial built-in application support functionality.
The Name Spells it Out
Using CICS means the customer controls how their information is presented and processed in a real-time processing model. It is as simple as that. But how? A customer system analyst designs the input and output maps that are presented on the display device. The analyst chooses the access methods and update integrity (syncpoint/rollback) to use. The analyst decides if the design has many smaller modules that interact with one another or is deployed as a few large programs packed with functions. Designers of applications make these types of decisions and have done so for decades.
Programming Team Uses CICS Extensions
Once the application design is completed, the customer programming team codes the programs using the operating-system-like services that are provided by the CICS system. For sending and receiving application screens, there are terminal commands. For access methods, the same just different commands. For interaction between modules, there are commands that support a link or a transfer of control. In total, there are about 400 CICS commands in 40 categories, from Abend to Web services. The figure below shows a subset of commands that pertain to the example narrative that I used previously to discuss traditional design and programming decisions. I have left out details like map names and file names as they are not needed to make the main point of the command.
Macro Level and Command Level Programming
Everything that I have explained so far is straightforward. However, my path with CICS had a bumpy start. After three months of training, I graduated on a Friday and started my new assignment on Monday. For three months, I programmed a dozen modules as part of batch-processing applications. Never heard the acronym CICS the whole time.
My new assignment was writing online CICS transactions that were part of the billing application. Making the transition was a challenge compounded by the situation that the CICS application programs used the CICS Macro interface. In simple terms, that meant that our somewhat straightforward COBOL programs had assembler-language macros whenever there was a file read or write, terminal write or read and any communication with common routines by way of a link or transfer operation.
I wasn’t the only person facing the challenge, as all my classmates had to learn CICS and enough Basic Assembler Language (BAL) to code the macros correctly. There was more; we had to create definitions to reserve storage so the macros instructions could operate properly and not corrupt or overlay CICS reserved storage. We made a mess on a regular basis because we could not put all the pieces together in a coherent way. There were application and system failures that resulted in a lot of frustration.
System Programming with CICS
I left the company where I got my start after about a year and took my new skills to the marketplace. Fortunately, my next job had the latest CICS release that supported the Command-level interface and everything changed for the better. After about a year of programming new applications, I was offered the position of CICS system programmer.
What Does a CICS System Programmer Do?
In my new position, I installed maintenance and new releases of CICS. Maintenance of the software is done using System Modification Program Extended (SMP/E), which I still regard as a supremely powerful utility. The utility has three main commands—receive, apply and accept. The utility works with Function Sysmods, PTFs and APAR fixes. At the time, that language seemed quite abstract to me. A few years later, I met the guy in IBM who had a big influence on the creation of that utility, and after working with him I developed a better understanding and appreciation of this tremendous utility. Later, I developed and taught a 1.5-day course to other system programmers on how to use it most effectively.
At the time, CICS had a CICSGEN macro that was used to generate a new instance of a CICS system. CICSGEN was the way that IBM chose to pick the functions that you required, leaving out the ones not needed so the generated CICS system was no “bigger” than it had to be. Working with CICS in an environment where storage and CPU resources were highly utilized meant that efforts were always made to make decisions in favor of efficiency.
What Else Besides Maintain and Install CICS?
I spent a lot of time looking at application dumps and making my analysis available to the application developers. It was one of my jobs to support them, so helping them debug their code was useful in moving their projects forward. CICS has very good ways to help programmers figure out the cause of a failure, but it takes some guidance and experience to figure out what remedial steps to take. Occasionally, there was a system ABEND and it was my job to figure out what was going on at the time of the system failure and call the IBM support center to get help. We had an on-site IBM Product Service Representative (PSR) some days and I could reach out to him directly to get help. Old-school PSRs were cosmic debugging humans. I was basically a one-person help department.
On occasion, I was called upon to create BAL programs that were an extension to CICS itself. CICS had terminal error (TEP) and node error (NEP) programs that were called automatically when there was a terminal or node error. My program had to perform application-specific cleanup. Since I knew about application programs, I knew what to do to clean up when an exception happened that called the error program. Programs often saved context information using keys like terminal id plus transaction id and put this “context data” to CICS temporary storage (TS). Cleanup meant deleting the data in TS so another transaction could start over fresh at the terminal.
Online Transactions Meant the Helpdesk Received Calls
CICS system programmers often work with operations on procedures. Operations would get a call that a user could not access a transaction or their terminal was hung up. The helpdesk needed to take remedial action. When an organization was just getting started with online transaction processing, people needed procedures to follow to help users. As a way of transferring skills, CICS system programmers helped create lists of steps to follow to help resolve common problems. Sometimes we created Command Lists (CLISTs) to perform the tasks in a semi-automated manner.
This was the early days of thinking about automated operations. Operator and helpdesk productivity was a part of what we tried to address. Later, we started to trap messages and take actions automatically. We also initiated active monitoring so we were not completely dependent of messages indicating that there was a problem. Active and passive monitoring are the two sides of the monitoring and management coin.
CICS Continues to Grow and Change
The experiences recapped above look back to the early days of CICS acceptance. Much has happened since this time. What has changed? CICS adoption has grown to the point where it is a significant workload on mainframe computers. Fueled by this growth, changes were made to CICS to make it more manageable under the strain of such widespread adoption. Implementations spreading work over different kings of CICS regions, like terminal owning and application owning address spaces, were designed for manageability and performance. CICS tools developed and were continuously refined to help as well. CICS was enhanced to embrace the web and new languages like Java.
The next article in this two-part series will focus on the enhancements that were made to CICS to make it even more useful to today’s application developers.