Improving event processing performance

CICS® Event Processing (EP) consists of three main components: capturing an event, dispatching the EP adapter, and emitting the event by running the EP adapter. For each component, different factors influence performance.

Factors when capturing an event

For CICS performance associated with running EP, consider the following factors:

  • Processor usage is negligible with EP started and no event binding file installed.
  • Processor usage is negligible with EP started and event binding files installed, but when the capture point is not defined in any <locationFilter> (the capture point and application command predicates) element in any of the Event Capture Specifications.
  • For primary predicate matching, use of the attribute filterOperator="EQ" ('Equals' specified in the filtering predicate) can result in improved performance, compared to other filterOperator values. An optimization is used when filterOperator="EQ" is specified.
    Note: The CICS event binding editor uses an asterisk (*) to show the primary predicate for the capture point selected.
  • If you are using <dataCapture> elements (Emitted Business Information items mapped in the Information Sources part of the capture specification) to capture specific parts of the data associated with a capture point, keep the number of <dataCapture> elements reasonably low. Otherwise, performance can be adversely affected, because a separate container is created for each data capture component. For example, if bytes 0 - 5, 10 - 15, 20 - 25, 30 - 35 of a record associated with an EXEC CICS WRITE command are to be captured, it is more efficient to define a single <dataCapture> element to capture bytes 0 - 35 than to define four <dataCapture> elements for each of the separate data areas.
  • Where possible, do not include unnecessary filter predicates. For example, it is often not necessary to filter on both the transaction ID and the current program name.
  • Put the filter predicates that exclude the most unwanted events before the filter predicates that exclude fewer unwanted events.
  • Where possible, do not use filter predicates on zoned decimal or packed decimal data fields that might contain unusable data.

CICS statistics in the EVENTBINDING GLOBAL STATISTICS category show the Total Event Filter operations. For more information, see EVENTBINDING statistics.

Factors when dispatching the EP adapter

EP runs multiple dispatcher tasks, which run on L8 TCBs, to service the emitting of events. These dispatcher tasks count toward the limit set by CICS for the number of L8 and L9 mode open TCBs. CICS sets this limit automatically using the formula (2 * MXT value) + 32. So that EP does not monopolize the L8 TCBs, the maximum number of L8 TCBs used for EP dispatchers is limited to one third of the open TCB limit. CICS statistics in the EVENTPROCESS STATISTICS category show the peak event capture queue and the peak dispatcher tasks so that you can monitor the use of L8 TCBs by EP. For more information, see EVENTPROCESS statistics.

Adapters can be either attached or linked depending on the adapters configuration. Attaching a task for each event increases processor usage; using the attach method means that the event dispatcher task does not wait for the event to be emitted to continue processing the event queue.

When a transaction ID or user ID is specified in the CICS event binding editor adapter section, the adapter is attached as a separate task. When a transaction ID or user ID is not specified, the adapter is linked to from the dispatcher task. However, the HTTP EP adapter is always attached.

Factors when emitting events by running the EP adapters

The cost of running the EP adapters depends on the EP adapter that is being used:
TSQ
The TSQ EP adapter imposes the least cost in terms of CPU consumed.
WebSphere® MQ
Each event has an MQPUT1 call for the WebSphere MQ EP adapter.
Assured event emission: You need the capability and reliability of assured event emissions to build business-critical application extensions based on events. However, assuring event emission (using synchronous emission mode) transfers the cost of event emission from an asynchronous event processing task to the application thread. Therefore, assured event emission could have an adverse affect on application response time, similar to adding an MQPUT for the event to the application itself. Because of the effect on response time, consider carefully which events demand the added level of reliability that is achieved through synchronous emission mode. Asynchronous emission mode is the better choice when it is less important that an event is occasionally lost (between the time an event is captured but not yet emitted); for example, for mail applications when an event is infrequently lost. Specifying synchronous emission mode only where it is needed ensures that your business is making the best use of assured event emission with the least impact on performance.
HTTP
Each event has a WEB OPEN, WEB CONVERSE, and a WEB CLOSE call for the HTTP EP adapter. By default, CICS closes the client HTTP connection after the event is emitted, and a new connection is opened for the next event. CICS can keep client HTTP connections open after events are emitted, so that they can be reused for subsequent event emissions, and you can save the processor overhead for reopening the connections. To keep connections open, specify the SOCKETCLOSE attribute in the URIMAP resource that the HTTP EP adapter uses for the connection. Choose an appropriate expiry time for the connections based on your emission rate.
A CEPH task is attached for each event emitted using the HTTP adapter. The CEPH transaction has a DTIMEOUT value of 5 seconds so that the HTTP EP adapter tasks timeout if a connection cannot be established with the event server within 5 seconds. The CEPH task then emits the event to an HTTP 1.1 compliant server. CICS provides a PROFILE for the CEPH transaction called DFHECEPH. This profile has an RTIMOUT value of 5 seconds so that the HTTP EP adapter tasks timeout if the event server does not respond within 5 seconds. You can copy this profile and the CEPH transaction if you want to change them.
  • If the emission rate is high compared to the HTTP 1.1 compliant server or network response time, these CEPH tasks can flood the CICS system resulting in the MXT limit being reached. You must copy the CEPH transaction and then assign your transaction to a transaction class to avoid the MXT limit being reached. The transaction class must have a MAXACTIVE value low enough to avoid reaching the MXT limit, and a PURGETHRESH value set to a non-zero value.
  • Any CEPH tasks that are purged when the PURGETHRESH limit is reached do not emit their events. Any tasks purged when the PURGETHRESH limit is reached result in the following message being written to the CSMT transient data destination: DFHAC2036 Transaction CEPH has failed with abend AKCC.
Note: When you use the copied profile or transaction, you must change your adapter configuration in the Event binding editor to run the HTTP adapter using this new transaction.
Transaction start
The transaction start EP adapter starts a new CICS task. Therefore, processor usage increases overall because of starting the transaction that is driven as a result of the CICS event. Also, each data capture field is made available to a started transaction in a container. A large number of these CICS tasks can impose a significant increase in processor usage on the adapter.

CICS statistics in the EVENTPROCESS STATISTICS category show the number of the following events:

  • Events dispatched to the WebSphere MQ EP adapter
  • Events dispatched to the HTTP EP adapter
  • Events dispatched to the Transaction EP adapter
  • Events dispatched to the TSQ EP adapter
  • Events dispatched to the Custom EP adapter

For more information, see EVENTPROCESS statistics.

CICS region storage for event processing

Event processing uses 64-bit (above-the-bar) storage in the CICS region. Your use of event processing therefore influences the value that you choose for the z/OS® MEMLIMIT parameter that applies to the CICS region.

If you use the temporary storage queue (TSQ) adapter and select main temporary storage, this data is also in 64-bit storage.

For information about the MEMLIMIT value for CICS, and instructions to check the value of MEMLIMIT that currently applies to the CICS region, see Estimating, checking, and setting MEMLIMIT. For further information about MEMLIMIT in z/OS, see Limiting the use of private memory objects in the z/OS MVS Programming: Extended Addressability Guide.