Resetting and deleting reattachment events

Retrieving an atomic event (but not a composite event) from the reattachment queue automatically causes the event's fire status to be reset to NOTFIRED. You can follow this sequence that an activity might use to handle reattachment events.

About this task

Retrieving a composite event from the reattachment queue does not reset the event's fire status to NOTFIRED, because a composite event is only reset when its predicate becomes false. Thus, if an activity program retrieves a composite event, it should reset the fire status of the sub-event or sub-events that have fired. (One way of doing this is to issue one or more RETRIEVE SUBEVENT commands.) This in turn causes the fire status of the composite event to be re-evaluated.

If the activity was reattached because of the completion of one of its children, it should issue a CHECK ACTIVITY command to check whether the child activity completed normally. On return from the CHECK ACTIVITY command, CICS deletes the activity completion event from the parent's event pool.

If the activity was reattached because of the expiry of a timer, it can issue a CHECK TIMER command to check whether the timer expired normally. On return from the CHECK TIMER command, CICS deletes the timer event from the activity's event pool.

If the activity wants to delete input and composite events from its event pool, it can issue DELETE EVENT commands. Alternatively, it can rely on a RETURN ENDACTIVITY command, issued on its final activation, to delete them.

Figure 1 shows a typical sequence that an activity might use to handle reattachment events. The Handle atomic event box is expanded in Figure 2.

Figure 1. Handling reattachment events. The Handle atomic event box is expanded in Figure 2 . The figure shows multiple reattachment events being handled in a single activation—you may prefer to handle one per activation.
The picture is a flow chart showing how an activity might handle reattachment events. At the top of the chart is a RETRIEVE REATTACH EVENT command. Depending on whether the retrieved event is an atomic or composite event, different paths are followed.If the retrieved event is an atomic event, the activity handles it in the way described in the next picture. It then checks for more reattachment events on the reattachment queue. If there are more reattachment events on the reattachment queue, the activity loops back to issue another RETRIEVE REATTACH EVENT command. If not, it issues an EXEC CICS RETURN.If the retrieved event is a composite event, the activity issues a RETRIEVE SUBEVENT command. It handles the retrieved atomic event in the way described in the next picture. It then checks for more atomic events on the sub-event queue. If there are more atomic events on the sub-event queue, the activity loops back to issue another RETRIEVE SUBEVENT EVENT command. If not, it decides whether the retrieved composite event is still required. If it isn't, it issues a DELETE EVENT(comp-event) command. The activity then checks for more reattachment events on the reattachment queue. If there are more reattachment events on the reattachment queue, the activity loops back to issue another RETRIEVE REATTACH EVENT command. If not, it issues an EXEC CICS RETURN.
Figure 2. Handling atomic events
The picture is a flow chart showing how an activity might handle atomic events. There are four elipses, representing the four types of atomic event—system, input, activity completion, and timer.If the retrieved event is an input event, the activity decides whether the event is still required. If it isn't, it issues a DELETE EVENT(input_event) command.If the retrieved event is an activity completion event, the activity issues a CHECK ACTIVITY command.If the retrieved event is a timer event, the activity issues a CHECK TIMER command.The activity then processes the event according to its internal rules for dealing with different types of event.
Note:
  1. Figure 1 shows multiple reattachment events being handled in a single activation. This may not always be appropriate. You may want always to retrieve only one reattachment event per activation, even if there is more than one event on the reattachment queue. This could be the case if, for example, you want a syncpoint to be taken between each processing step. (Note especially that a child activity that is run asynchronously is not started until a syncpoint occurs when its parent returns. Dealing with many reattachment events in the same activation could delay the start of the child.)
  2. The figures show input and composite events being explicitly deleted by means of DELETE EVENT commands. This is not always strictly necessary—see Using the ENDACTIVITY option of the RETURN command . Similarly, it may not always be necessary to issue CHECK TIMER commands. If you don't, timer events can be deleted by means of a RETURN ENDACTIVITY command issued on the activity's final activation.