Activity processing

Activity processing is organized in two activations. The first activation sets up the environment. The second activation starts when a defined external interaction occurs.

About this task

To set up the environment to enable the second activation to take place, the first activation must:
  1. Define an input event that depicts the external interaction. The activity cannot now complete until this input event has been dealt with.
  2. Obtain an activity identifier that uniquely identifies this activity-instance. To do this, it issues an ASSIGN command.

    The transaction that starts the second activation must use this identifier to gain access to the activity.

  3. Save details of the activity identifier and input event to a suitable medium. For example, a VSAM file or WebSphere MQ queue, to which the transaction that starts the second activation has access.
  4. Return without completing. (That is, issue an EXEC CICS® RETURN command on which the ENDACTIVITY option is omitted. Because of the user event in its event pool—the input event that it has defined—the activity does not complete but becomes dormant.)
When the external interaction occurs—for example, a clerk enters some data at a terminal—the transaction that starts the second activation of the activity is invoked. This transaction must:
  1. Retrieve the activity identifier and input event
  2. Gain access to the activity by issuing an ACQUIRE ACTIVITYID command that specifies the activity identifier.
  3. Reactivate the activity, and specify why it is being activated by issuing a RUN ACQACTIVITY command that specifies the input event.

Figure 1 shows an activity that interacts with the outside world. The first activation sets up the environment, saves details of the activity identifier and input event to a VSAM file, and returns without completing. Some time later, a user starts the SPAR transaction from a terminal. The SPAR transaction retrieves the activity identifier and input event, issues an ACQUIRE ACTIVITYID command to gain access to the activity, supplies the activity with some input data, and reactivates it.

Figure 1. Acquiring an activity. On its initial activation, the activity sets up the environment and returns without completing. Some time later, the SPAR transaction is started from a terminal; it retrieves the activity identifier and input event, issues an ACQUIRE ACTIVITYID command to gain access to the activity, and reactivates it.
The picture shows two activations of an activity and a separate transaction, SPAR, that is started from a user terminal. On its first activation, the activity defines an input event, obtains an activity identifier, saves the name of the input event and the activity identifier to a file, and returns without completing. The sequence of commands it issues are: DEFINE INPUT EVENT, ASSIGN ACTIVITY, WRITE FILE, and RETURN.Some time later, the SPAR transaction is started from a user terminal. It retrieves the activity identifier and input event, issues an ACQUIRE ACTIVITYID command to gain access to the activity, and reactivates it. The sequence of commands it issues are: READ FILE, ACQUIRE ACTIVITYID, PUT CONTAINER() ACQACTIVITY FROM(), RUN ACQACTIVITY INPUTEVENT(), and RETURN.

Subtopics

Parent topic: Interacting with BTS processes and activities

dfhp907.html | Timestamp icon Last updated: Thursday, 27 June 2019