Examining CICS TS 4.2 event processing improvements

The Customer Information Control System Transaction Server (CICS TS) for IBM mainframe systems is a core part of financial institutions and other organizations that need reliable real-time transaction processing for the mainframe. IBM’s new CICS version, CICS TS 4.2, became generally available this past June, and its many changes include several notable enhancements to event processing. This tip summarizes the event processing improvements and examines what they mean for system programmers.

Assured event emission
CICS TS 4.2 introduces an option to synchronize event emissions in the primary transaction’s unit of work. This means the transaction will not end normally unless CICS successfully propagates the event. Conversely, the message won’t be emitted if the transaction ends badly. This feature may extend event processing to applications that need message integrity. However, as is always the rule with asynchronous processing, the fact that a message successfully left the chute doesn’t mean it arrived safely. For example, when using IBM WebSphere MQ as a transport, an application can be sure MQ successfully queued and delivered the event message, but there is no assurance it will be successfully processed by the message consumer. 

Change management
Change management is one of the stickier points to event processing, as capture specifications can be very detailed, down to field values within a file record. For example, a bank has a capture specification that triggers events whenever a savings account balance goes below $25. Then, for some reason, a programmer lengthens the packed decimal balance field by a byte. The event capture specification as written will now emit an event when balances go below $2,500.

To partially address this issue, IBM introduced the EP Search tab (Figure 1) within the event binding editor

Figure 1: IBM’s new EP Search tab

The tab has many options to refine or expand the search through event bindings and active CICS regions. After a programmer makes a change, he or she can look for events that might be affected based on resource names, copybooks or structures, and fix potential conflicts in the editor. The next challenge is ensuring the program and event bindings move into production at the same time.

Although adding the EP Search tab is a good start, having a disciplined programmer to follow a conflict resolution process is crucial. Future enhancements ought to include the ability to export and import event bindings into a flat file, which might have several advantages. First, an installation could use the flat file to automate a change resolution process. The flat file could also be treated like source code and folded into existing lifecycle management. Finally, when the time comes to move to production, a change process could move the flat file and import it into the production system.

Event resource management
In CICS TS 4.1, event adapter specifications are part of the event binding definition that led to several management problems and inefficiencies. For example, the bindings waste a lot of space redefining the same adapter several times in a bundle. Conversely, adapter changes have to be propagated to each event in the binding.

CICS TS 4.2 addresses this issue by decoupling event and adapter definitions. Now, an event binding need only reference a predefined adapter, and CICS will make the connection at run time. While this makes life easier for a systems programmer, it does require vigilance to ensure the proper adapters are defined where the events need them. Enterprises also have to be wary of adapter definitions of the same name that have different attributes. These are old resource management issues for CICS, (transactions and profiles share the same relationship), but if this is too daunting, you can still include adapter definitions within the binding.

System events
To date, most threshold-monitoring automation relies on inaccurate and inefficient sampling techniques. Now, the monitoring is built in as CICS TS 4.2 introduces system event emission. Here, CICS emits events for state changes in files, DB2 connections, max task (MXT) and transaction classes. CICS will produce events when a file becomes enabled, disabled, opened or closed. The same goes for connecting or disconnecting the DB2 interface. IBM nicely broke up MXT and transaction class monitoring into percentile thresholds, beginning at 60% and up to 100%, emitting events whenever the system crosses the threshold up or down. Lastly, CICS may produce events for transaction ABENDs.

CICS includes a lot of system information with each event. However, the event binding editor enables you to specify context and include application data in the emitted event.

These types of events should prove to be very useful. According to IBM, the monitoring logic is deep within CICS and produces little overhead. Because of the internal view, the results will also be much more accurate and timely. However, there may be some instances where system events may not work as desired. For example, as the CICS manuals warn, a task emitted to process a MXT event while CICS is at max task is not going to run immediately, as it will have to wait until the MXT condition ends. In fact, dropping a new task on an already overcrowded system may make the situation worse.

CICS TS 4.2 has some other smaller changes:

• The event binder recognizes some new data types for capturing and emitting events, which can simplify event capture and emission. With this change, programmers will be able to process these data types as formatted values instead of hexadecimal strings.
• Temporary storage queue adapters can now participate in Representational State Transfer (REST) and WebSphere Business Events (WBE) events with the addition of XML format support. Thus, programmers can process these new types of structures through the more familiar technique of passing information through temporary storage queues.

Additional systems programming interface commands with detailed information about capture specifications will facilitate better CICS operation and problem determination.

The introduction of event processing in CICS TS 4.2 is an interesting development. I look forward to future releases that may expand the scope of system events and make the resources more manageable.

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 assorted other mainframe products. He has programmed in Assembler, Rexx, C, C++, PL/1 and COBOL. The latest phase in his career finds him an operations architect responsible for establishing mainframe strategy and direction for a large Insurance company. He lives and works with his family in south Texas.

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.