Activation sequences

To complete all its work, an activity might need to run as a sequence of separate processing steps, or activations . For example, a parent activity typically needs to run for a while, stop temporarily, and then continue execution when one of its children has completed.

Each activation is triggered by a BTS event , and consists of a single transaction. First activation of the activity is triggered by the system event DFHINITIAL, supplied by BTS after the first RUN or LINK command is issued against the activity. (In the case of a root activity, DFHINITIAL occurs after the first RUN or LINK command is issued against the process. It is possible to issue multiple RUN or LINK commands against a process - see Using client/server processing. ) When the last activation ends, the activity completion event is fired, which might, in turn, trigger another activation of the activity. See BTS events.

Figure 1 shows a BTS activity being reattached in a series of activations.
Figure 1. A sequence of activations
The picture shows a sequence of three rectangles, representing successive activations of the same activity. The first two rectangles contain the words "EXEC CICS RETURN". The third and final rectangle contains "EXEC CICS RETURN ENDACTIVITY". An arrow named "1", representing the DFHINITIAL event that first wakes up the activity, points to the first rectangle. An arrow named "2", representing a subsequent reattachment event, points to the second rectangle. A similar arrow points towards the last rectangle. An arrow named "3", representing the activity completion event, points away from the last rectangle.
1
The first event that “wakes up” the activity is DFHINITIAL. The activity determines that the event which caused it to be activated was DFHINITIAL and therefore performs its first processing step. Typically, this involves defining further events for which it might be activated. The activity program issues an EXEC CICS RETURN command to relinquish control. The activity “sleeps”.
2
The next event occurs and “wakes up” the activity. The activity program determines which event caused it to be activated and performs the processing step appropriate for that event. It issues an EXEC CICS RETURN command to relinquish control.
3
Eventually, no more processing steps are necessary. To confirm that its current activation is the last, and that it is not to be reactivated for any future events, the activity program issues an EXEC CICS RETURN ENDACTIVITY command. The activity completion event is fired.
Note: Root activities do not have completion events.
Figure 2 is a comparison between a terminal-related pseudoconversation and a BTS activity that is activated multiple times.
Figure 2. Comparison between a terminal-related pseudoconversation and a BTS activity that is activated multiple times
The picture shows two lists of commands, one representing a terminal-related pseudoconversation and the other a BTS activity. The pseudoconversation has the following sequence: EXEC CICS RECEIVE MAP select (some_state) when(first_time) ⋮ when(xxxx) ⋮ when(finished) ⋮ end select EXEC CICS SEND MAP EXEC CICS RETURN TRANSID(xxxx) An arrow, pointing back to the top, is labeled "Loop controlled by CICS via the terminal".The BTS activity has the following sequence: EXEC CICS RETRIEVE REATTACH EVENT EXEC CICS GET CONTAINER select (some_state) when('DFHINITIAL') ⋮ when(xxxx) ⋮ when(finished) ⋮ end select EXEC CICS PUT CONTAINER EXEC CICS RETURN An arrow, pointing back to the top, is labeled "Loop controlled by CICS via the activity".
Note: The RETRIEVE REATTACH EVENT command issued by the activity retrieves the name of an event that caused the activity to be reactivated. The GET and PUT CONTAINER commands retrieve and store input and output data.