How CICS event processing works

You can configure CICS® to detect and emit application events or system events. When a specified event occurs, CICS collects data and triggers a synchronous or asynchronous process, through an EP adapter.

CICS can be configured to detect and emit both application and system events from the later stages of CICS Initialization through until the end of the first stage of CICS shutdown. Event processing is started before the second phase of CICS initialization PLT processing begins, and quiesced after first phase of CICS shutdown PLT processing completes. However, events triggered by any new tasks which are started by a CICS shutdown PLT program are not guaranteed to be detected.

Figure 1. Event processing high-level architecture
This diagram shows the CICS event binding editor being used to define application event capture points, system event capture points, and event processing adapters. The captured events are then passed to the event dispatcher for formatting and emission to various EP adapters. These events can then be consumed by WebSphere Business Events, WebSphere Business Monitor, or other event consumers.
Note: IBM Business Monitor, formerly known as WebSphere Business Monitor.
  1. You specify when to capture and emit events by using the CICS event binding editor.
    • An event binding is created in a CICS bundle project
    • The criteria for capturing an event and the data to be included within the event are known as capture specifications and are saved in event bindings. Each capture specification relates to a particular capture point, for example following the EXEC CICS READ FILE API call or the point at which a file enable status is changed.
    • The event emission options including the required format and destination are specified in an EP adapter.
  2. You export the bundle to the z/OS UNIX file system and install it into CICS by using a BUNDLE resource.
    • CICS creates EVENTBINDING and EPADAPTER resources from the BUNDLE.
  3. CICS checks for active capture specifications whenever an event capture point is run.
    • If capture specifications are active at the capture point, CICS checks the filter criteria and captures the specified data for any that evaluate true.
  4. Captured events are passed to the event dispatcher for emission.
  5. The event dispatcher passes each event to the EP adapter specified for the event binding.
  6. The EP adapter formats the event and emits it to a destination according to its configuration options.

How the event is processed after it has been captured depends on the Emission mode and Transactional mode of the EP adapter used to emit it.

Transactional mode

Transactional mode can be used to control whether event emission is dependent on the success of the capturing unit of work.
  • Non-Transactional: Events are available for emission as soon as they are captured.
    • Use non-transactional when you want the event emitted regardless of whether the capturing unit of work completes successfully. For Example, an event for Order Attempted should be emitted non-transactional because you would want it to be emitted even if the unit of work did not complete successfully and the order was not placed.
    • Events can be emitted even if the capturing unit of work backs out, therefore it is possible to get events even if something was backed out or never committed, and also duplicate events as work is tried again.
    • A benefit is that you do not have to wait for sync point before the event can be emitted, this transactional mode can be useful if capturing events from long running tasks, as events are emitted immediately.
  • Transactional: Events are emitted if and only if the unit of work from which they were captured completes successfully.
    • Use transactional only when you want the event to be emitted if a task completes successfully. For example, the Order placed event should be emitted only if the order was completed successfully.
    • As events are not emitted for units of work that are backed out or not committed, duplicate events are avoided if work is tried again.
    • A disadvantage is that if capturing the events from a task which waits a long time between sync points the events will be emitted some time after they actually occur.
    • Transactional emission is not available for system capture points. System events are typically not transactional and you would not want to wait for a system unit of work to complete before emitting a system event; you would want to emit the system event as soon as possible. You will receive a DFHEC1023 error message in the CICS message log after the emission of the first system event for any event binding which references a transactional EP adapter.

Emission mode

Emission mode can be used to control whether an event is emitted asynchronously, or as part of the capturing unit of work.
  • Asynchronous: When an event has been captured it is added to a dispatcher queue. Control is returned to the unit of work from which it was captured and the event is formatted and emitted asynchronously.
    • Use Asynchronous emission wherever possible because it has less impact on the response time of the capturing application and does not change its behavior. Specifically it should be used when the capturing unit of work can be considered complete even if the event fails to be emitted. For example, an Order over $1,000 event that is used for statistics, monitoring, or targeting promotional offers should be emitted asynchronously as the order is complete and valid with or without the event.
    • For asynchronous emission the recoverability of the transport is not a concern because the correct transactional behavior is achieved by CICS either emitting the event immediately or waiting for sync point.
    • Event emission failures do not change the behavior of the application.
    • A benefit is that asynchronous emission has a low performance impact on capturing application.
    • A disadvantage is the potential to lose events that failed to emit, for example, due to network outages or across a CICS restart. Applications from which the events were captured can complete successfully regardless of whether the event was emitted, therefore the emission of events with emission mode asynchronous is not assured.
  • Synchronous: When an event has been captured it is formatted and emitted as part of the unit of work from which it was captured. If the event fails to be emitted the capturing transaction will be backed out at sync point with an ASP7 abend code.
    • Use synchronous emission when the capturing unit of work is considered incomplete if the event failed to be emitted. For example, when an Order placed event is used to trigger the next step in an event driven order handling process.
    • The behavior of the application can be affected by event emission failures. For example, when emitting an order placed event, orders cannot be processed if your event consumer in unavailable.
    • A benefit is that events are not lost if they fail to be emitted because the actions which caused them are backed out and therefore never happened. Events defined with an emission mode of synchronous are assured and can be used as part of event driven processes.
    • A disadvantage is that there is a greater performance impact on the application. Consider the impact to response times as formatting an emission of the event now takes place on the applications thread.
    • Synchronous event emission is not available for system event capture points. Since system events are typically used for statistics and monitoring they do not typically have the requirement for synchronous emission. A DFHEC1024 error message is received in the CICS message log after the emission of the first system event for any event binding which references an EP adapter that is defined with synchronous emission mode.