One of the more interesting new features of CICS Transaction Server 4.1 is event processing. Event processing enables an application to emit events as it goes about its daily business without changing any code. In Addition, CICS TS 4.1 introduces a new command, EXEC CICS SIGNAL EVENT, for creating explicit events.
The concept is fairly simple. A CICS program calls an application programming interface (API). When an API call matches the criteria specified in a "capture point" predicate, CICS grabs the information specified in the event definition and passes this on to the "event processing adapter." The adapter may optionally massage or "enrich" the data before passing it on to the event consumers.
Note that CICS creates simple events, the equivalent of, "Hey, this just happened!" More complex events, for example, more than five withdrawals of $100 or more in one day, require some kind of process to collect and analyze the individual events from CICS. IBM recommends WebSphere Business Monitor (WBM).
Capturing events in CICS TS 4.1
Automatic event processing covers a multitude of CICS commands. For a full list, refer to the table in the CICS TS 4.1 Infocenter with the topic "Event Processing/How CICS supports event processing." CICS triggers most events after the command completes normally. Others, such as an EXEC CICS LINK, generate events before the command executes. You may also capture events for the non-API event of program initialization.
An event predicate is a set of filter criteria CICS uses to decide if the API call constitutes an event. Examples of criteria include transaction context and command resource names along with some other information that varies by command. CICS can also make decisions based on data in the command parameters (e.g., file I/O buffer) but cannot use information in some other location, such as working storage.
The predicate should be chosen carefully. Too simple of a predicate will generate a blizzard of events. Too specific of a predicate will incur a lot of overhead while CICS goes through the qualification process. Automatic event capture does not apply to DB2, MQ or IMS calls. However, you may use the EXEC CICS SIGNAL EVENT command to generate events with data from a communications area (COMMAREA) or channel.
Once CICS decides to emit an event, it looks to the event definition to see what application information should be included. Again, this information could be transaction context as well as fields within command data areas -- for instance, account balance or part number. Finally, CICS passes all the pertinent data to the event adapter.
CICS event adapters
CICS passes the collected information to an event adapter. These are the ones available:
- An MQ message
- Another CICS transaction
- Write the event data to a temporary storage queue
- Send an HTTP message (available through APARs PK94205 and PM07361).
- Custom adapter
The adapters emit the event information in a variety of formats. There are a couple XML-based formats: Common Base Event (CBE) and WebSphere Business Event (WBE), which is aimed at WBM. In addition, there is CICS Flattened Event (CFE) for the MQ, started transaction and TS queue type adapters. HTTP adapters can produce CBE-, CBER- and WBE-formatted messages.
Event process tooling
IBM supplies event process tooling as the event binding editor (EBE) in CICS Explorer. The process begins by starting the new bundle project wizard, which walks through the various steps to defining the capture point and the data meant to go along in the event, ultimately creating a bundled event bind file.
The choice of application data can be pretty specific. Fortunately, EBE can import language structures, enabling the user to pick the fields out by name instead of offset. EBE is also smart enough to figure out the field's length and format. Note, however, that this means any changes to the structure must be propagated to EBE and the movement of the event bind file must be carefully coordinated with application changes on the host.
EBE allows several options for influencing event behavior. One, "transaction option," tells CICS to not emit the event until the driving transaction takes a sync point. Conversely, CICS backs out the event if things end badly. This can be very good if the business rules require data to be committed before generating an event. This can be more troublesome for a long running task that might execute for a while before committing changes.
Once the event is fully defined, the user tells EBE to export the generated event bind file to a Z File System file on the mainframe. CICS must, in turn, have a bundle defined pointing to that same directory. When CICS scans the directory, it will define the bundle and the event.
I'm sure many people are wondering about event processing overhead. IBM insists the overhead is very low because the logic for capturing events is in the API code itself instead of some sort of bolt-on component. They do warn, however, that the price of event processing does go up depending on the number of event definitions and their predicate complexity.
ABOUT THE AUTHOR: For 24 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.
What did you think of this feature? Write to SearchDataCenter.com's Matt Stansberry about your data center concerns at firstname.lastname@example.org.