Dec 9 ’13

CICS Version 5.1: Faster, Bigger, Better

by Nick Garrod in Enterprise Tech Journal

This third and final piece of the IBM CICS Version 5.1 puzzle addresses the performance and scalability enhancements and new capabilities introduced in this latest version. We’ll examine how you can run more work in a single CICS region and how you may be able to combine CICS regions to save additional CPU, and present some performance measurements and release-to-release changes. We’ll also examine new resource policies that allow you to put rules in place to prevent transactions, or groups of transactions, from exceeding predefined thresholds and actions you can take if transactions exceed that threshold. We’ll also examine some of the scalability tooling available to help you determine what your transactions are doing to help you set these parameters and policies correctly. 

Performance: Version-to-Version

CICS V5 focused on operational efficiency and service agility. The operational efficiency area of CICS focused on the capacity of the CICS region from two aspects, vertical and horizontal scalability. Vertical scaling is achieved by allowing more tasks to run within a single CICS region. Typically, there are two constraints, CPU and storage. The storage constraint in the 31-bit area was increasingly becoming an issue. In CICS Transaction Server Version 5.1, we moved control block structures above the bar into 64-bit storage, providing relief in the 31-bit area, allowing you to run more work. These enhancements help avoid short-on-storage conditions and can reduce the need for additional CICS regions.

The MAXTASK limit has been doubled to 2000. We continue to look at non-threadsafe resources in CICS in an effort to further reduce TCB switching. For horizontal scaling, we ran CICS side-by-side, and have implemented several instrumentation enhancements to show how the platform is actually performing. We collected additional information on specialty engine usage, such as how much work could run on specialty engines and how much work actually ran. There are also several simplification exercises that CICS now performs for you; for example, the system initialization table looks at the various parameters and sets them in the table to a more reasonable number; this means that in many cases, CICS calculates what a number should be rather than having it specified manually. For example, the MAXOPENTCBS and MAXXPTCBS parameters are now automatically set based on the MXT value for the region. 

In terms of an upgrade, what are the performance differences between CICS TS V4 and CICS TS V5? Figure 1 shows the results from a COBOL/VSAM workload running in 34 CICS regions, four Terminal-Owning Regions (TORs) and 30 Application-Owning Regions (AORs). VSAM Record Level Sharing (RLS) and a temporary storage server were used. There are an average of six file requests per transaction with a mixture of read, read for update, update, add and delete. There’s little business logic in the workload, so it’s a measure of the cost of the CICS functions. These results are run at different transaction rates between 5000 and 16000 Transactions Per Second (TPS); you can see the CICS workload percentage of LPAR utilization and the cost of the transaction. Once averaged, you can see that the movement between releases is minimal.

We ran the same workload on Version 4.2 in 30 regions and again on V5.1, but consolidated to 10 regions. We found that we could run the same external throughput (TPS), but we had a reduction in CPU, so we did the same amount of work, saved MSUs, but had 20 fewer CICS regions to keep track of. Further results show that a VSAM workload uses about half the number of real storage frames by running fewer regions, and fewer working sets reduce the load on the operating system. Furthermore, there was an 11 percent reduction in cycles and cache misses, so moving to V5.1 means you can consolidate your AORs. 

Greater Capacity

Greater capacity is delivered through significant vertical and horizontal scalability enhancements. New and improved capabilities provide the features and benefits highlighted in Figure 2.

The CICS transient data facility and further API and SPI commands have been made threadsafe. Additionally, CICS no longer switches to the Resource-Owning (RO) Task Control Block (TCB) to load a program when an application is already running on an open TCB. Instead, CICS carries out the program load on the open TCB. These enhancements can increase throughput and reduce CPU usage.

CICS TS V5.1 supports Java 7, which provides a range of benefits to make it easier for developers to write and optimize Java code. Java applications can now access Java Database Connectivity (JDBC) and SQLJ from a T8 TCB, instead of switching to an L8 TCB; this can significantly improve the performance of Java applications.

CICS TS V5.1 supports non-Language Environment (LE) Assembler language programs that run in 64-bit addressing mode (AMODE(64)), providing 64-bit application support to access large data objects. This lets you run more workload in a single region to provide vertical scaling; the TCB usage will allow more dispatchable units to be run, providing horizontal scaling, and Java 7 will provide throughput along the way.

Managed Operations

Managed operations are provided through the introduction of policies to deliver automated control over critical system resources (see Figure 3). Users can set data access thresholds on SQL or file access requests through a user task. For example, you could set a threshold that abends any task that runs in a banking region that tries to use 24-bit storage because everything should be using 31-bit storage, or receive a notification if a task tries to get more than 1 MB of storage. There’s a policy that’s part of an XML document created by the CICS Explorer that consists of a threshold and an action.  

CICS policies are a declarative way of ensuring applications and platforms continue to run effectively. A policy can be applied to any combination of applications and platforms. Additionally, policies can be deployed into a single region, independently of defining a platform. Policies are applied dynamically during production operations.

Increased Availability

We examined all the cases when it was necessary for sites to either take CICS down or take some action to upgrade a resource (see Figure 4); our immediate focus was on sites introducing a new release of CICS. We’ve introduced a CICS utility that will upgrade the SVC table without the need for an IPL. This allows users to bring in a new release of CICS and move in the new SVC without an IPL. The need to shut down CICS to update the CICS SSL certificate is eliminated through the provision of a refresh command.

With more people using IP inter-connectivity and going external to their own environment, firewalls can create difficulties by closing connections if they aren’t used frequently enough. We’ve introduced a heartbeat capability so CICS IP sessions don’t get closed automatically, such as by a firewall with no notification provided, until you want to use the connection. IBM issued a Statement of Direction on an active-active availability policy for the Geographically Dispersed Parallel Sysplex (GDPS), and CICS has declared that V5.1 has functionality to support the future functions with VSAM for an active query or an active standby configuration in the GPDS active-active policy/directional statements. There are also several default values set for best practice configurations.

Deeper Insight

Improved decision-making and easier auditing have been achieved by taking a deeper look into the CICS environment. Suppose you initialized your CICS region two weeks ago and now the run-time parameters don’t match what you originally set. CICS now provides an audit trail of changes so you can see what changes were made, and when and how they were made.

Changes were made in security verification. Many users access CICS using the Web, and for performance reasons, the system does a fast verification of the combination of user ID and password. In the new version of CICS, at least one full security check a day runs and updates the security manager, preventing accounts from being disabled due to inactivity.

Changes have been made to the identity propagation function (introduced in V4.1), which is used in transaction routing, for dynamic program links (DPLs) and in function shipments. In V5.1, the ID propagation function has been extended from function shipments and DPLs to include EXEC CICS starts.

Performance monitoring capabilities are improved, including identifying the cipher suite that was used and specialty engine usage (and possible usage) for potential financial cost savings.

Enhancements to Core CICS

Enhanced CICS events allow a system event to be sent when a specific message is issued or when a write-to-operator event is issued. We now have the concept of adapter sets, so a single event can now output to multiple targets (previously, there was a single target). The CICS-WebSphere MQ DPL bridge now provides support for a channel and a container, so we’re able to move beyond the 32 KB limit, and we now have IPIC support for IMS (transaction manager) for the asynchronous start and retrieve functionality (see Figure 5).

Policies can be applied to everything running in a given CICS region and can be achieved by defining the policy—regardless of whether it’s CICS Explorer, packaged in a bundle or installing a bundle definition in CICS. The resource policy will apply to everything. In previous articles, we examined cloud technology and the underlying application and platform technology. This policy can be applied to a given platform, so everything running in this platform is now affected by this policy. Similarly, we can also apply a policy to a specific application so this particular application has a resource threshold policy, or we can apply a policy inside an application in terms of application context.

There are several challenges facing users who want to take advantage of these polices:

• What to set as resource policies and how to do it?
• What’s the typical transaction view in terms of the number of file requests and link/sequel requests?

CICS Performance Analyzer (CICS PA) lets you look at the CICS performance records and extract any number of pieces of information about your CICS system. One of these pieces will help you set polices. CICS PA can help you nurture the performance of your CICS environment. You can use it for ongoing systems management and measurement, to create reports to keep track of your CICS performance and to do trend analysis. CICS PA can be used to diagnose performance issues within CICS. Using SMF records, it can help you track, process and tune your CICS system to optimum performance. It can produce a single report showing all the CICS performance along with your MQ or DB2 performance. CICS PA comes with more than 240 supplied reports, ranging from CPU analysis, response time analysis, CPT analysis and so on. CICS PA integrates with the CICS Explorer and lets you view report data graphically. CICS PA gives you performance insight for TS V5.1, supporting all the new metrics for CICS TS V5.1 (see Figure 6).

CICS Independency Analyzer (CICS IA) is a discovery tool that captures information about your CICS applications, transactions and programs and the resources they use. This gives you the ability to conduct threadsafe analysis (see Figure 7). In CICS IA V5.1, you can generate a threadsafe report through the CICS Explorer plug-in (see Figure 8). This report lets you scroll by region, by transaction and by program. It can show you the commands it ran, whether or not it was threadsafe, and whether it was a command that uses shared resources and may therefore not be appropriate to make threadsafe. For more information on threadsafe, see the Redbook Threadsafe Considerations for CICS (SG24 6351). This report will help you determine which programs you can make threadsafe and which programs require some work before they can be made threadsafe. Once you’ve used CICS PA to determine threadsafe candidates, the next step is to use CICS IA to determine what the transactions are doing, what commands they’re issuing and if they’re doing any dynamic calls.

To help with the performance of your CICS system, CICS VSAM Transparency V2.1 is a tool that migrates VSAM data to DB2 while allowing your application programs to remain unchanged. Major inhibitors to upgrading to DB2 and taking advantage of the value DB2 provides, such as 24x7 availability, or having a new distributed application that needs to have access to data and update the data, are the time and cost associated with rewriting your application programs. VSAM Transparency allows you to migrate to DB2 without having to do a wholesale modification to your application programs. You can upgrade on a file-by-file basis. Over time, you can open a program, modify a program to make use of SQL, and uninstall VSAM Transparency, as it’s no longer required.

Conclusion

CICS 5.1 delivers a mix of operational efficiency, performance, capacity and scalability enhancements as well as service agility with the introduction of cloud concepts into CICS with platforms and applications. We’ve introduced new ways of interfacing your applications with Liberty and Liberty Application Profile, servlets and JavaServer Pages for CICS. These improvements will help you move forward with CICS while remaining competitive and able to react to change without breaking business processes or compliance agreements.