Author’s Note: This article reflects on the many years of CICS technical support and what it was like for the pioneers of early releases. Many of you will fondly remember what we went through, and hopefully, the more recent supporters of CICS will appreciate how far the product has come. It’s been a privilege to meet many talented, dedicated customers and IBMers through the years, but now it’s time for me to pass along insights into the simple inner workings of CICS and how we got to where we are.
The CICS product developers and change team at IBM Hursley in the U.K. are talented, dedicated folks who have the unenviable job of both fixing the bugs that show up and constantly producing a better, more efficient product. They do an awesome job and show strong commitment to quality and it’s been evident in CICS through the years.
Challenges and Opportunities
Although CICS/XA 1.7 wasn’t the first release, it posed many challenges to those who installed it in 1985. There were many enhancements back then—major enhancements to those of us who welcomed them. At this point, however, CICS was still supported by source code, not Object Code Only (OCO). To install, or service the product, you would have to practically regenerate all the components from scratch.
Unfortunately, some installations chose to use the source code and do their own “customization.” They felt their requirements weren’t being met by the base product, so they chose to address these items with a “modified” CICS. This was dangerous and difficult to support with each new release, and almost impossible for IBM to diagnose any problems. IBM couldn’t anticipate what changes were made, and when an outage was reported, they were unable to determine whether the problem was in the CICS code or customized code. Needless to say, it was a challenge.
CICS/XA 1.7 was the first release to support dynamic installation of terminals, or auto-install. Previously, installations had to make additions to their Terminal Control Table (TCT) for each new terminal, reassemble the table into a new load module, and recycle the region. Can you imagine doing that today?
TCP/IP and the Internet didn’t exist; we all used 3270 terminals—affectionately known as “green screens.” Customers that had large networks spent considerable time maintaining them, but in those days, large networks could contain more than a thousand terminals. Sometimes, we would run these “gens” or macro generations limited times, since they consumed a great deal of CPU, which was expensive back then. Often, we would have to submit them late in the day and wait until the next morning to see if they were successful. Since DASD (disk) space was also limited, we would hope they didn’t run out of space when creating the new load module. It was a laborious, painful process.
Terminal auto-install let us produce a “model” that CICS could use to make a dynamic control block for these devices; we were ecstatic. Now, terminals are dynamically installed, as are most network connections, sessions, etc.. CICS/XA 1.7 also delivered an upgraded file control component that let the data set name be included in the File Control Table (FCT) so files could also be dynamically allocated or deallocated to any region. Thank you, Hursley! Remember when CICS regions had to be brought down at night so batch jobs could access the files? It’s hard to believe but true.
Any of you who use Interactive Problem Control System (IPCS) to debug system dumps will be amazed to learn that the CICS verb exit DFHPDnn didn’t yet exist. CICS dumps could be imported into IPCS, but debugging them involved “chasing chains” in control blocks using the IBM Data Areas manual to find contents of control blocks. One IBMer had written this exit for internal use only, and when some of us were given access to it, we immediately lobbied for it to be incorporated into the base product. The SHARE CICS Project played a large part in this effort. Finally, DFHPDX was born and delivered with the next release. Those familiar with the verb exit now use the release-supported component and it’s delivered as DFHPDnn, where each new release number is incorporated into the CICS library of the product.
The CICS SHARE Project
SHARE is an amazing, life-changing organization. The volunteers selflessly work to educate and support all CICS practitioners with sessions that are indisputably the most helpful in the industry. During the early years, SHARE played a vital role in the evolution of CICS.
SHARE has a Requirement Committee that has been instrumental in submitting customer requests to IBM. When customers found out that CICS was going to be OCO, IBM actively asked installations what they thought should be incorporated into the new product. Remember, many customers had customized the product to do what they felt needed to be done. Requirements were submitted to incorporate these features into the product and the SHARE CICS project members were tasked with prioritizing them. Many didn’t make the cut, but it gave IBM direction. When the first OCO version of CICS was delivered, many requirements were incorporated. SHARE contributed greatly in this way.