BTS activities and processes

An activity is the BTS unit of execution. It holds the environment for an instance of the BTS equivalent of program execution. The state of a BTS activity is stored on disk and re-instantiated in memory as required. Typically, it represents one of the actions of a business transaction.

Activities can be hierarchically organized, in a tree structure that may be several layers deep. The activity at the top of the hierarchy is called the root activity. An activity that starts another activity is known as a parent activity. An activity that is started by another is known as a child activity. For example, if activity A starts activity B, B is a child of A; A is the parent of B. Notice that--with the exception of the root activity, which has no parent--an activity can be both a parent and a child.

A process is the biggest entity recognized by BTS. It consists of a collection of one or more activities. It always contains a root activity. When a process is run, the program that implements its root activity receives control. Typically, a process is an instance of a business transaction.

Processes can be categorized, using the PROCESSTYPE option of the DEFINE PROCESS command. All the activities in a process inherit the same PROCESSTYPE attribute. Categorizing processes makes it easier to find a particular process--the BTS browsing commands allow filtering by process-type.

Names and identifiers

When a program defines a process, it gives the process a name (its process name), which is used to reference the process from outside the BTS system. This user-assigned name, which can be up to 36 characters long, must be unique within the process-type to which the process belongs.

Similarly, when an activity program defines a child activity, it gives the child a name (its activity name), which it will use to reference the child. This user-assigned name, which can be up to 16 characters long, only needs to be unique within the set of child activities defined by the parent. For example, it is perfectly valid for several activities within the same process to each define a child called Invoice.

Note:
A root activity always has the CICS®-assigned name DFHROOT.

Besides its name, each activity has a CICS-assigned activity identifier. An activity identifier, which is 52 characters long, is a means of uniquely referring to an activity-instance. It is guaranteed to be unique across the sysplex, and its lifetime is the same as the activity it refers to. Activity identifiers are frequently used as arguments on inquiry and browsing commands. Only its parent can refer to a child activity by name; other programs can access the activity by means of its identifier.

Activation sequences

To complete its entire work, an activity may need to execute as a sequence of separate processing steps, or activations. For example, a parent activity typically needs to execute for a while, finish execution temporarily, then continue execution when one of its children has completed.

Each activation is "triggered" by a BTS event, and consists of a single transaction. An activity’s first activation 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.2 ) When the last activation ends, the activity completion event is "fired", which may, in turn, trigger another activity’s activation. See BTS events.

Figure 2 shows a BTS activity being reattached in a series of activations.

Figure 2. 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 may 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 3 is a comparison between a terminal-related pseudoconversation and a BTS activity that is activated multiple times.

Figure 3. 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.

Synchronous and asynchronous activations

You can cause an activity or process to be activated in one of two ways:

Synchronously
The activity or process is executed synchronously with the requestor. Exactly how it is run varies, depending on which command is used to activate it:
LINK
The activity is included as part of the current unit of work; all locks and resources are shared with the requestor. The activity runs with the transaction attributes of the requestor; any transaction attributes (TRANSID or USERID) specified on its resource definition are ignored. In other words, there is no context-switch.
RUN SYNCHRONOUS
The activity is run in a separate unit of work from that of the requestor, and with the transaction attributes (TRANSID and USERID) specified on its resource definition. In other words, a context-switch takes place.

The two units of work are linked; if the requestor backs out, the activity is backed out also.

Asynchronously
The activity or process is executed asynchronously with the requestor, following a RUN ASYNCHRONOUS command.

The activity is run in a separate unit of work from that of the requestor, and with the transaction attributes (TRANSID and USERID) specified on its resource definition--that is, a context-switch takes place.

Checking the response from a child activity

After a parent has requested a child activity to be run, it must check the response from the child by issuing a CHECK ACTIVITY command. This is because the response to the request to run the activity does not contain any information about the success or failure of the child activity itself--only about the success or failure of the request to run it.

Typically, in the case of a synchronous child activity, the CHECK ACTIVITY command is issued immediately after the RUN command. For an asynchronous child activity, it could be issued:

If the child activity needs more than one processing step (transaction) to complete its work, on return from its first activation it will not be complete. The CHECK ACTIVITY command returns the current completion status.

Following the execution of a CHECK ACTIVITY command issued by its parent, if the child activity has completed, its completion event (and its name) is deleted by CICS. The event cannot be deleted in any other way, because it is the completion of the activity.

For further information about the uses of the CHECK ACTIVITY command, see Dealing with BTS errors and response codes.

Lifetime of activities

A child activity is created when its parent issues a DEFINE ACTIVITY command. It is destroyed:

Processing modes

An activity is always in one of the following processing states or modes:

ACTIVE
An activation of the activity is running.
CANCELLING
CICS is waiting to cancel the activity. (A CANCEL ACTIVITY command has been issued, but CICS cannot cancel the activity immediately because one or more of the activity’s descendants are inaccessible. This can happen if, for example, one of the activity’s children holds a retained lock.)
COMPLETE
The activity has completed, either successfully or unsuccessfully. The value returned on the COMPSTATUS option of a CHECK ACTIVITY command tells you how it completed.
DORMANT
The activity is waiting for an event to fire its next activation.
INITIAL
No RUN or LINK command has yet been issued against the activity; or the activity has been reset to its initial state by means of a RESET ACTIVITY command.

Figure 4 is a (slightly simplified) view of how the processing modes relate to each other. The BTS commands that cause an activity to move from one mode to another are shown in uppercase.

Figure 4. Activity mode transitions. The words in uppercase are the commands which cause the transitions.
 The picture contains five elipses, each of which represents one of the five activity processing modes listed in this section. The elipses are interconnected by arrows that represent the BTS commands that cause the transition from one mode to another. There is one inward arrow, marked "DEFINE", to the Initial mode. There are three outward arrows from the Initial mode: one marked "DELETE"; one, marked "RUN or LINK", to the Active mode; and one, marked "RUN or LINK", to the Dormant mode. There are two inward arrows to the Active mode: one, marked "RUN or LINK", from Initia; the other, also marked "RUN or LINK", from Dormant. There are two outward arrows from the Active mode: one to Dormant and one to Complete. There are two inward arrows to the Dormant mode: one, marked "RUN or LINK", from Initial; the other from Active. There are four outward arrows from the Dormant mode: one marked "DELETE"; one, marked "RUN or LINK", to Active; one, marked "CANCEL", to Cancelling; one, marked "CANCEL", to Complete. There is one inward arrow, marked "CANCEL", to the Cancelling mode, from Dormant. There is one outward arrow from the Cancelling mode, to Complete. There are three inward arrows to the Complete mode: one from Active; one, marked "CANCEL", from Dormant; one from Cancelling. There are two outward arrows from the Complete mode: one marked "DELETE"; one, marked "RESET", to Initial.

To discover the current mode of an activity, use the CHECK ACTIVITY or INQUIRE ACTIVITYID command.

User syncpoints

Start of changeA program that is running as the activation of a BTS process cannot issue user syncpoints (EXEC CICS SYNCPOINT commands). Some examples of programs that may issue user syncpoints are:

End of change

Related concepts
BTS data-containers
BTS timers
BTS events
What are CICS business transaction services?
The Sale example application
Related reference
Process- and activity-related commands

2.
It is possible to issue multiple RUN or LINK commands against a process. However, this is not discussed in this section--see Using client/server processing.

[[ Contents Previous Page | Next Page Index ]]