Get Started With CICS Performance and Tuning

This article begins with focus on mainframe CICS but as it progresses, the focus shifts to CICS on all platforms, a progression that matches the product’s development. While techniques discussed are initially mainframe-based and oriented to CICS Transaction Server (TS), most principles and concepts apply to all processing platforms; syntax, parameters and implementation specifics may vary, but CICS functions (under names like TXSeries, Transaction Gateway and ICS TS) is the consistent target of discussion.

The first question when starting a tuning project is: What should I look for? With CICS, tuning has changed dramatically over the decades. When I joined IBM in 1978, CICS/Virtual Storage (VS) was a single-platform (mainframe), single-region product that enabled alphanumeric-only, monochrome (green screen), 3270-based applications, processing business functions like order entry/inquiry, customer service, accounting, shipping, etc. I recall re-generating a CICS/DOS system on a small IBM computer, trimming every possible feature to fit the system within available real storage. Tuning was simple back then; the only processing resources to tune were processor utilization, real storage, a few CICS parameters and application code.

VS, a 24-bit addressing scheme that expanded a region to 16 MB (minus OS storage) complicated CICS/VS tuning, because more storage and DASD enhancements meant more real-time data could be processed. Data set layout, channel speed, utilization, disk rotation time and arm movement, and buffering now became vital. Tuning was no longer limited to processor utilization, real storage, some CICS parameters, and user code; I/O became another crucial tuning skill. Relieving one bottleneck only to reveal another became a tuning characteristic.

Real storage was still pretty limited on System/370 processors, and paging performance quickly became a major issue. High-end IBM processors had an instruction execution time around a hundred nanoseconds, and page data transfer was measured in milliseconds, so performance was drastically degraded when the processor had to wait for a page operation a million times slower than its execution time. Multiprogramming mollified that effect, but CICS was a single Task Control Block (TCB) implementation, meaning all transactions waited on a page operation. Page tuning became a new skill to add to the tuning list, fueling rapid online growth.

The online systems explosion generated a new constraint; virtual storage tuning. Between system software (e.g., MVS, DFP, RACF, CICS, etc.) and application (e.g., code and working storage) growth, VS within the CICS region was curtailed. Virtual storage—which diminished real storage constraints—was now constrained itself. CICS evolved Intercommunication to enable Terminal, Application or File Owning Regions. CICS function could now be spread across multiple regions, and more System Initialization Table parameters addressed VS performance. New releases further improved VS usage.

The mainframe’s workload diversified, largely because it was no longer the only player in IT. Midrange systems like IBM’s System/3x evolved into AS/400 as a smaller mainframe alternative, initially used standalone, but soon communicating with mainframes, followed by the PC with similar network requirements. Telecommunications evolved from analog to digital; Local Area Networks, T1 and fiber-optics revolutionized networking. Network tuning became mandatory, assuming the complexity and sophistication of computer tuning. Bandwidth, routing, compression and other verbiage became standard vocabulary in data centers with private networks, key to CICS performance in terms of response time.

As a consequence of workload diversification, workload management gained great significance. IBM developed Workload Manager (WLM)—a component of the z/OS system—and since has been extended to AIX and other OSs. WLM uses definitions (e.g., Service Classes, Goals, Importance Levels, Response Time) to monitor the work mix running on various platforms, modifying job priorities, I/O processing and all system performance characteristics for all processing complex work. It controls which work gets computing resource based on WLM definitions, including CICS.

CICS aggressively expanded into the internet as it flourished, with new functions like CICS Web Interface, CICS Sockets, Command Level Interface (EXEC CICS WEB/DOCUMENT commands), password authentication and SSL support, plus other web function. Even more impactful was the emergence of CICS Transaction Gateway and TXSeries for Multiplatforms, a distributed CICS online transaction processing (OLTP) environment for mixed language applications on AIX, Windows Server, Encina, Linux, etc. CICS now runs on varied platforms, interacting with CICS TS and peer nodes. This has been an area of rapid tuning growth.

The distributed network of interconnected CICS’s imposed a significant expansion of tuning methods and techniques for systems programmers or administrators, because each platform is constructed somewhat differently. Tuning takes different forms like program caching, reducing remote procedure call registrations and shared class caching, and common tuning tasks like migration to new releases, optimizing dataset layout, parameter optimization, tuning buffer pools and threads/sessions/connections (logical portals between network CICS nodes). CICS has become an all-platform OLTP environment, and so has its tuning.

Categories of CICS Tuning

CICS or any IT tuning methodology is hardly a static matter. Since the very early days of CICS, tuning the most widely used and dominant product in the history of IT has been an evolving discipline that changes with product and technology.

CICS tuning’s history provides a valuable starting point for performance enhancement, because the progression of tuning tasks and categories is a list of items that may be relevant for implementation if they’re germane to the performance study’s objectives. The specific tasks listed below are examples, a subset of all tuning tasks:

First-generation tuning, processor and real storage constraints:

• Optimize CICS processor utilization via System Initialization Table parameters, MVS dispatching priority and other techniques
• Review real storage usage and allocate as much as possible to CICS
• Review startup options in general
• Upgrade to a faster computer if possible
• Modify applications to remove CPU-intensive function where possible. Modifying applications is a last-ditch effort due to effort and complexity.

Second-generation tuning, DASD and I/O constraints:

• Evaluate data set layout, channel transfer, utilization, disk rotation time and. most important, buffering. Balance data activity via dataset relocation and movement, reorganize datasets to optimize I/O.
• Increase CICS buffer allocations, monitor impact on virtual and real storage
• Use VSAM Shared Buffers
• Validate region sizes to make optimum use of virtual storage

Third-generation tuning, paging performance constraints:

• Evaluate page data set layout, reorganize to minimize contention
• Modify CICS parameters
• Split CICS systems to spread activity across TCBs if possible. This is a difficult undertaking due to resource sharing requirements.
• Add real storage if possible to reduce paging

Fourth-generation tuning, virtual storage constraints:

• Split CICS Regions
• Optimize DSA settings

Fifth-generation tuning, network throughput and connectivity constraints:

• Identify network bottlenecks and add capacity or reconfigure traffic
• Add CICS sessions between nodes (e.g., mainframe and downstream TXSeries)

Sixth-generation tuning, WLM configuration constraints:

• Compare job performance to WLM settings, modify to prioritize high priority work
• Increase importance of tasks locking resources to improve resource availability

Seventh-generation tuning, CICS web processing constraints:

• Optimize mainframe CICS web processing via internal parameters
• Upgrade TXSeries to newest release, tune program caching in downstream nodes

What’s Next?

Performance information needs to be gathered to determine where bottlenecks and excessive resource consumption exist, what factors curtail response time, what priorities and performance objectives are being missed, and what constraints listed above might need tuning. Drilling down reveals options which may resolve performance issues; they need to be prioritized, vetted and tested. The process has begun. Care needs to be taken in moving changes to production. Change control dictates timing, and backout procedures need definition. Measurement criteria need to be established and data collected to determine impact and for comparison purposes.

A Moving Target

The progression I’ve just described demonstrates the principle that CICS tuning isn’t just a matter of modifying CICS, regardless of the platform it runs on. Numerous IT components are involved, and it’s constantly evolving. Each generation of tuning builds on previous ones. Once tuning categories and constraints are delineated, a starting point for improved performance is established. Understanding CICS internals and tuning options, and detecting and revealing performance constraints are only the beginning. Performance monitoring and data collection will be the next article’s topic.

---