CICS TS Performance and Tuning: A Rich Tradition

It may sound geeky, but one of my favorite discussion topics—usually limited to a client’s system programmers and sometimes manager—is CICS Transaction Server (TS) performance and tuning. Sysprog is a group I’m very comfortable with, because there aren’t a lot of times I can share an acronym-laden conversation with a bunch of enthusiastic groupies passionate about efficiency.

I joined IBM in 1978 and was immediately assigned to a leading-edge CICS/VS account. Its transaction volume was immense for the time, and because the online system was strained to the very limits of throughput and response time, the IBM CICS development lab in Hursley, England, was very interested in their experience.

I was assigned to take all IBM CICS/VS courses and basic training as soon as possible in Endicott, N.Y., which meant I spent very little time at home, but it was time well spent. I’d present the material I’d been taught with my client—which, due to their superior skills, was like taking the class again on steroids—and simultaneously I brought state-of-the-art CICS information to them. I quickly became very proficient with the transaction server, and while I stayed deeply involved with my client, IBM promoted me to CICS Regional Designated Specialist supporting CICS across the Midwestern U.S. and other locations as needed.

Processor utilization had always been a performance concern, but the biggest performance issue in those days was virtual storage constraint. CICS was still a single address space implementation, so there was no such thing as a terminal-, application- or file-owning region, which would allow CICS function to be spread across multiple regions. Furthermore, MVS was limited to a 24-bit addressing architecture, which limited address space size to 16 megabytes, about half of which was consumed by MVS, VSAM, IMS database and other system software.

Especially for CICS/VS implementations, these virtual storage limitations often created crises, and I found myself making performance visits to one CICS customer after another. CICS could manage storage shortages via a process called program compression, but compressions were very costly in terms of processor utilization, so the analysis had to also address processor consumption. Performance constraints tend to be a cascading process, so virtual storage and processor constraints tend to degradee I/O or data access performance and real storage depletions, often reflected by high paging rates.

Most virtual storage performance and tuning reviews required a broad, all-encompassing investigation that addressed all aspects of processor efficiency, I/O capacity and real storage. Since the truest reflection of performance is response time, some attention would also be given to network configuration and bandwidth, but it was secondary because mainframe was the focus, so network performance was usually assigned to the telecomm staff. Internal mainframe response time, however, was key.

CICS Tuning Checklist

As I continued to conduct performance studies and produce reports that were a combination of observations and recommendations, patterns began to emerge, and over time I developed a standard methodology. Each client had unique characteristics, but there were many items that were typical performance review components. For example, there were usually four areas of investigation:

1. Virtual storage usage represented by storage compressions in the CICS shutdown statistics
2. Real storage usage represented by paging rates in SMF records
3. Processor utilization in SMF records
4. I/O activity in SMF records

Furthermore, CICS provided initialization and runtime parameters that could have a profound effect on each of the performance categories. It became apparent it should be possible to construct a checklist that, once the offending performance category(s) were identified, could provide direction in tuning measures to streamline processing. Enhancing efficiency became an exercise in modifying parameters or taking actions like data set reorganization, targeted at specific performance constraints or user response time, and which could be turned into a checklist. Furthermore, the checklist could be broken down by CICS component or module (e.g., task control, terminal control or file control).

These considerations made good sense, not just in concept, but also on paper. In addition to my regional and branch responsibilities, I’d also served an internship with the IBM Dallas System Center (DSC) CICS Support Unit, which provided the opportunity to run my checklist idea past some members who strongly encouraged me to continue, going as far as to suggest publishing it as a DSC Bulletin. I continued to write, deeply committed by now, and shortly thereafter completed a rough draft. I still have that manuscript.

Evolution to the CICS Performance Guide

Meanwhile, a friend at DSC initiated contact with Hursley CICS development regarding my tuning checklist and guide, and the CICS publications manager expressed strong interest. We both attended a GUIDE user conference, and met to discuss my work and Hursley’s vision of a CICS Performance Guide, which would including my tuning information and checklist, and expand to include performance data collection, measurement techniques and additional CICS performance components such as the CICS monitoring facility, CICS trace and interfaces to products such as Workload Manager (WLM).

Up to this time, any tuning methodology was word-of-mouth or customized to client, so—to my knowledge—the tuning guide was the first process formalization and official part of IBM documentation. CICS was designed to be tailored, a table-driven architecture where everything from System Initialization Table to CICS Trace was tunable, and installation options or storage allocations could be used to optimize performance, but without guidance. The CICS Performance Guide provided that, providing directions, identifying parameters or options with the greatest impact, and showing how to interpret performance data/reports to determine optimum tuning steps.

CICS led the way in software performance and tuning, not just via my tuning checklist, but also from DSC representatives and clients. They’d battled constraints and challenges of rapidly growing online systems before I joined IBM, finding ways of getting more out of less, passing ideas to development for integration and in user presentations. I gathered these tips and techniques, structure the information in a useful checklist, organized in order of importance and effectiveness, and elaborating each checklist item. I wasn’t the discoverer, I was the documenter, expanding the discussion into queuing theory and tuning methodology.

Having set the CICS performance and tuning historical perspective, it continues to evolve, and is more important with broader context. CICS TS has expanded function, from the critical capability of intercommunication primarily responsible (along with 31-bit addressing) for breaking the restraints of virtual storage to include:

• Enhanced file/database interfaces, migrating from a VSAM internal interface to external Transactional VSAM, from an IIMS database internal interface to external IMS Database Control, and adding a richly functional external interface to relational database (DB2)
• Implementing numerous functionally varied forms of internet/web support
• Implementing a facility called business transaction services
• Creating an interface to the MVS System Logger, replacing internal logging facilities
• Replacing internal security mechanisms with an External Security Interface implemented by security software products (e.g., RACF)
• Implementing Java support and applications
• Implementing numerous other facilities and enhanced virtually all components

The Past Leads to the Future

While CICS performance and tuning has evolved, it’s also become more important than ever. I recently worked with a client that processed up to 400 million transactions daily, running hundreds of CICS copies concurrently, processing stupendous transaction volumes that fuel the banking industry, enabling the world economy to function. The CICS TS Performance Guide has kept pace with product evolution.

While there are rumors the mainframe is dead, there are tens of thousands of CICS licenses handling the largest business volumes worldwide that prove this isn’t the case. The mainframe is a vital component of IT, and CICS is a vital component of the mainframe.

---