For years, CICS grew horizontally to meet availability and throughput goals. CICS Transaction server 5.1 has undergone some changes that may enable installations to consolidate workloads into fewer regions.
On Oct. 3, IBM announced the open beta
Doing more with fewer in TS 5.1
IBM included improvements for reducing trust control block (TCB) switches. Version 5 adds transient data (TD) commands to the thread-safe pantheon, along with changes, to let Java programs execute SQLJ calls directly from their Java virtual machine. In addition, program loads will now be done in the open TCBs, thus avoiding switches to the resource-owning task.
CICS 5.1 expands 64-bit storage usage to include main temporary storage, storage and program control blocks. Most CICS management modules can now access 64-bit channels and containers directly instead of copying them to 31-bit storage first. Assembler application programmers can get in on the fun by using the new GETMAIN64 commands. Note that CICS TS 5.1 will not start with an above-the-bar memory limit less than 6 GB.
Lastly, 5.1 introduces new system management features that reduce the need for planned outages. For instance, a new utility installs the CICS type 3 supervisor call instruction without an IPL. More useful, perhaps, are new options that refresh SSL certificates without bouncing CICS and keep IP interconnectivity working.
This CICS version extends system events to include messages. The primary predicate for these events is the message ID, which can be further filtered by transaction or user ID. Also available at the time of the event are "inserts" which make up the variable information CICS inserts into the message. You may find the inserts and their number designations in the messages and codes manuals.
Message event processing is a possible game-changer for CICS automation because hooks set in CICS' message domain should be more efficient than outboard automation packages that monitor the console or extrapartition data queues. There are, however, a couple of limitations. First, message event processing is unavailable before the event domain initializes during CICS startup and after it ends during termination. Second, it only works for DFH* and EYU* messages. Users will still need traditional automation methods for messages from z/OS, subsystems or applications.
CICS TS 5.1 takes another step forward with policy-based management. This feature allows an enterprise to set up policies outlining certain transaction performance thresholds and what should happen when they're crossed. So far, the monitors look at, among other things, file I/O, SQL call metrics and memory-related metrics. The actions CICS may take when a task crosses a threshold include issuing a message, ABENDing the transaction or emitting an event.
You set these policies up in CICS Explorer. A policy rule consists of one condition -- i.e., a transaction makes more than 10,000 SQL calls. One or more policy rules can be rolled up into a policy, while any number of policies can be rolled into a bundle containing descriptions of CICS resources.
CICS also includes a scope designation to describe where the policy applies. The scope can be from one region to an entire CICSPlex.
Policy-based management presents another opportunity for CICS customers to replace clunky in-band automation. It will be interesting to see what other performance metrics may come under policy scrutiny in the future or if there will be any integration with operating system policy managers such as Workload Manager.
CICS Server Platform as a Service
Another interesting development is CICS' positioning for platform service "cloud-style" deployment. This appears to be more than just co-opting buzzwords, because IBM bases a lot of this on existing concepts in the CICSPlex System Manger (CPSM) repository. The main thrust of this appears to be the abstraction of application and system definitions to make deployment and life cycle management, for lack of a better term, more "cloud-like."
On the application side, the systems programmer defines resources in CICS bundles. He or she groups these bundles together to create an application. On the system end, the administrator groups any number of regions into region types, similar to what is already done in CPSM CSYSGRP resources. The various groups will then be bundled into a platform.
Finally, someone builds the application-binding that maps the application resources into the region types of the target platform. Once the binding is done, the application and platform definitions can be deployed, at which time all the necessary resources will be created. If done correctly, systems programmers can keep the familiar terminal-owning regions and application-owning regions constructs, while at the same time be less concerned about working with individual regions. This could go a long way to avoiding some past problems caused when the wrong type of definitions appeared in the wrong regions.
In case you were wondering how CICS knows which transactions belong to an application, the application bundle includes an "entry point" definition. When CICS sees control pass through the entry point, it slaps the application context on it. This means the task can be monitored under the application's policy and CICS Monitoring Facility records will contain context information so application performance can be measured as a whole.
About the author:
Robert Crawford has been a systems programmer for 29 years. While specializing in CICS technical support, he has also worked with VSAM, DB2, IMS and other mainframe products. He has programmed in Assembler, Rexx, C, C++, PL/1 and COBOL. The latest phase in his career is as an operations architect responsible for establishing mainframe strategy and direction for a large insurance company. He works in south Texas, where he lives with his family.
This was first published in November 2012