The root activity

    EXEC CICS RETRIEVE REATTACH EVENT(Event-Name)
             RESP(data-area) RESP2(data-area) END-EXEC

The first time an activity is started during a process, the event returned is the system event DFHINITIAL. This event tells the activity to perform any initial housekeeping.

In this example, CICS initially invokes the DFH0SAL2 root activity as a result of the RUN ACQPROCESS command issued by the DFH0SAL1 program. As part of its initial housekeeping, DFH0SAL2 uses the EXEC CICS ASSIGN PROCESS command to discover the name of this instance of the business transaction (process). (The name of the process instance was assigned by the DEFINE PROCESS command, and might be, for example, a customer reference or account number.)

     EXEC CICS DEFINE ACTIVITY('Order')
                  TRANSID('SORD')
                  PROGRAM('ORD001')
              RESP(data-area) RESP2(data-area) END-EXEC

The DEFINE ACTIVITY command requests CICS business transaction services to add an activity to a business transaction (process). In this example, DFH0SAL2 adds an activity called Order to the Sale business transaction. It is implemented by program ORD001. The TRANSID option specifies that, if the Order activity is run in its own unit of work, it runs under transaction identifier SORD.

    EXEC CICS PUT CONTAINER(Sale-Container)
             ACTIVITY('Order') FROM(Process-Name)
             RESP(data-area) RESP2(data-area) END-EXEC

The input data is placed in a data-container named Sale (the value of the variable Sale-Container). The ACTIVITY option of PUT CONTAINER associates the Sale data-container with the Order activity.

The data put into the Sale data-container is the process name; that is, the unique reference that identifies this instance of the Sale business transaction. The process name in this case is the customer reference or account number specified on the DEFINE PROCESS command in DFH0SAL1.

    EXEC CICS LINK ACTIVITY('Order')
             RESP(data-area) RESP2(data-area) END-EXEC

The LINK ACTIVITY command causes the ORD001 program to be executed synchronously with DFH0SAL2 and to be included as part of the current unit of work. The TRANSID option of the DEFINE ACTIVITY command is ignored - LINK ACTIVITY causes the Order activity to run under the transaction identifier of the requestor, SALE.

The Order activity collects order details from the terminal operator and validates them. The ORD001 program converses with the terminal operator until the order is accepted. It then returns the validated details in an output data-container.

     EXEC CICS DEFINE ACTIVITY('Delivery')
                  TRANSID('SDEL')
                  EVENT('Delivry-Complete')
              RESP(data-area) RESP2(data-area) END-EXEC

The Delivery activity is to be executed asynchronously with the root activity. When an activity completes, its completion event fires. The EVENT option names the completion event of the Delivery activity as Delivry-Complete, and thus defines it. Defining the event allows it to be referenced and checked for.

CICS reattaches an activity on the firing of any event, other than a subevent, that is in its event pool. (An event pool of an activity contains events that have been defined to the activity, plus the DFHINITIAL system event.) Thus, the DFH0SAL2 root activity is attached again when the completion event of the Delivery activity(Delivry-Complete) fires.

    EXEC CICS GET CONTAINER(Order-Container)
                  ACTIVITY('Order') INTO(Order-Buffer)
             RESP(data-area) RESP2(data-area) END-EXEC
 
    EXEC CICS PUT CONTAINER(Order-Container)
                  ACTIVITY('Delivery') FROM(Order-Buffer)
             RESP(data-area) RESP2(data-area) END-EXEC

Here, the GET and PUT commands are used to transfer data from the output data-container of the Order activity to the input data-container of the Delivery activity (both of which are named Order). These are different data-containers, although they share the same name, they are associated with different activities.

    EXEC CICS RUN ACTIVITY('Delivery')
                  ASYNCHRONOUS
             RESP(data-area) RESP2(data-area) END-EXEC

Because RUN rather than LINK is used, the Delivery activity is executed as a separate unit of work, and under the transaction identifier specified on the TRANSID option of the DEFINE ACTIVITY command. (The RUN command always activates the specified process or activity in a new unit of work.) Because the ASYNCHRONOUS option is used, the Delivery activity is executed asynchronously with DFH0SAL2, and starts only if the current unit of work completes successfully.

• The creation of a new Sale business transaction
• Work done by the Order activity, and its input and output data; containers
• The request to run the Delivery activity, and its input data-container
• The condition under which the DFH0SAL2 root activity is to be reactivated.

After the CICS sync point, the menu of business transactions is displayed again on the terminal of the user, ready for further selection. The remaining activities are completed, without reference to the terminal user, under the control of CICS business transaction services. The DFH0SAL2 program no longer exists in memory, and the existence of this instance of the Sale business transaction is known only to BTS.

CICS business transaction services start the Delivery activity (SDEL) as requested. (BTS participates as a resource manager for the transaction.) On completion of the Delivery activity, BTS reactivates the Sale root activity; that is, the DFH0SAL2 program under the transaction identifier SALE.

As with the Delivery activity, DFH0SAL2 sets the parameters of the Invoice activity, input data, and execution options before requesting the activity to be run. It then issues an EXEC CICS RETURN command and becomes dormant, waiting to be reactivated for this instance of the Sale business transaction.