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.
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.
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.
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 3 is a comparison between a terminal-related pseudoconversation and a BTS activity that is activated multiple times.
You can cause an activity or process to be activated in one of two ways:
The two units of work are linked; if the requestor backs out, the activity is backed out also.
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.
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.
A child activity is created when its parent issues a DEFINE ACTIVITY command. It is destroyed:
An activity is always in one of the following processing states or modes:
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.
To discover the current mode of an activity, use the CHECK ACTIVITY or INQUIRE ACTIVITYID command.
A
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: