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.
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 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.