Start of change

How CICS assures event emission

You can assure emission of an event by using an EP adapter with synchronous emission mode and the appropriate transaction mode. With synchronous emission, event formatting and emission processing is completed synchronously within the unit of work of the capturing transaction. The unit of work completes successfully only if the event is emitted. The EP adapter is linked from the application task; that is, the event is not queued for asynchronous processing by an EP dispatcher thread or separate EP adapter task.

Synchronous event emission is not supported for system capture points therefore emission of system events cannot be assured.

Synchronous events can be transactional or non-transaction but the recoverability of the transport must be set up correctly in each case.

Synchronous non-transactional events:
The EP adapter must emit events to its transport in an unrecoverable manner so that the events are not backed out if the unit of work fails.
Synchronous transactional events:
The EP adapter must emit events to its transport in a recoverable manner so that transactional events are backed out if the unit of work is backed out.

Not all EP adapters can support synchronous emission with all combination's of TRANSMODE. For more information, see Event processing adapters.

When an event fails to be emitted, the EP adapter provides information about the event and why it was not emitted, increments relevant event statistics, and causes the unit of work for the capturing transaction to be backed out.

Considerations for planning

Understanding the way that synchronous event emission works helps you to understand how to make the best use of this capability. Some things to consider when you use synchronous event emission include: security, performance, transport, and effects on applications.

The event-capturing transaction must have write authority to the event emission transport (for example, the WebSphere® MQ queue for the WebSphere MQ EP adapter) for synchronous emissions; the EP dispatcher or adapter task that emits events needs write authority for asynchronous emission.

Synchronous, transactional event emission is recoverable. When you use the CICS WebSphere MQ EP adapter, events are put on the WebSphere MQ event queue under sync point; therefore, you might have to review your WebSphere MQ log data set space allocation. When you use the CICS TSQ EP adapter, this adapter increases the use of your recoverable TS queue so you might have to review your CICS log stream size and attributes. Using synchronous transactional events with a task that runs for a long time without taking a sync point can cause the log to overflow.

When using synchronous emission, a custom EP adapter must honor the EPAP_RECOVER flag in the DFHEP.ADAPTPARM container. For more information, see Custom EP adapter.

Assuring your event emission provides the opportunity to build business critical event-based applications, and extend existing applications in a reliable way. The trade-off is that the synchronous processing that is essential to assuring that events are emitted might have an impact on your application response time. A judicious use of synchronous event emission minimizes the application impact. See Event processing performance for more information about performance considerations when assuring event emission.

A single unit of work might cause many events to be emitted, where some events are transactional and some events are non-transactional. If a capturing transaction fails to emit a synchronous event, the unit of work is backed out with any transactional events that it captures. Non-transactional events might still be emitted.

The EP adapter, its resources (such as a WebSphere MQ queue), and the event consumer must be configured with enough capacity to process the expected peak volume of events to be emitted in order to prevent the capturing transaction from failing.

To help you decide where to use synchronous emission, here are some considerations for asynchronous and synchronous emission for comparison:

Consider the following characteristics when you are using asynchronous event emission:
  • The order in which events are emitted from a CICS® program can be different from the order in which they were captured.
  • The order in which events are emitted can vary from one run to another of an event-enabled CICS program.
  • Event emission is not assured. Events might be lost if CICS ends abnormally with events in progress. In the unlikely event of a CICS system failure after the capture of an event but before its emission, the event might not be emitted at all, regardless of whether the EP adapter in the event binding specifies that events are transactional.
  • The cost of formatting and emitting the event is offloaded to an event processing thread or to a separate transaction.
  • There is a minimal impact on the capturing transaction.
  • No changes are required to application code.
Consider the following characteristics when you are using synchronous event emission:
  • Events are emitted from a CICS program in the order in which they were captured.
  • Event emission is assured when the capturing transaction completes successfully.
  • Events can be considered as application extensions for business-critical data.
  • When synchronous emission is used with the WebSphere MQ EP adapter, event delivery can be assured.
  • The cost of formatting and emitting the event is added to the application thread.
  • There is a greater impact on the capturing transaction; for an event emitted on an application thread, an event emission failure causes the application to back out. Consider the capturing transaction configuration and the impact on overall system resource usage.
Parent topic: Concepts
Related information:
Event processing adapters
End of change