Audit trail examples

Follow the sequence of activations of a BTS process, SALES1234567890. The activities that make up the process run on two CICS® regions.

For clarity, the example does not show the activations of any other processes that might also be running in these regions.

Figure 1. Example audit trails. This table shows, for each audit level setting, the points at which audit records would be written. The letters in the columns are the names of the activities for which records are being written.
In the first column of the table are a number of boxes that represent the process and activities, described in the text, that run on system SYS1. In the second column of the table are a number of boxes that represent the activities, described in the text, that run on system SYS2. The last four columns represent the four audit-level settings - OFF, PROCESS, ACTIVITY, and FULL. At various points down these columns are letters, which are the names of the activities for which audit records are being written. For example, reading down from the top of the picture, at the point that activity B is activated the letter B appears in the "ACTIVITY" and "FULL" columns. In the "OFF" column, there are no letters. In the "PROCESS" column, the letter "P" appears at the point the process is defined and when it is run. The letter "R" appears at the three points the root activity of the process is activated, and when it completes. The "ACTIVITY" column contains all the letters in the "PROCESS" column, plus others for the descendent activities of the root activity - when they are activated and when they complete. The "FULL" column contains all the letters in the "ACTIVITY" column, plus others for the descendent activities of the root activity - when they are defined; when they are scheduled to run; when activity G is acquired; when activity G is canceled.

In this example, an application running on region SYS1 defines a new process, SALES1234567890, and requests it to run. The root activity of the new process begins running on SYS1. It defines and runs an activity B, which executes synchronously. When control returns to the root activity, it defines activities C and D and schedules them to run asynchronously. After the root activity has returned, activity C starts on SYS1 and activity D starts on SYS2.

Activity C schedules child activities E and F to run asynchronously and returns. E and F run on different systems. When each of its child activities completes, C is reactivated and checks the completion status of the child. Lastly, C completes normally, which causes the root activity to be reactivated.

Activity D defines a child activity G and schedules it to run asynchronously. Later, another transaction issues ACQUIRE ACTIVITYID and CANCEL ACQACTIVITY commands against activity G. G completes in a FORCED state. D is reactivated and discovers what has happened to G with a CHECK ACTIVITY command. In response to G's failure, D defines a new activity H and requests it to run asynchronously. D then returns and H runs on the other region. When H completes normally, D is reactivated and completes normally. This causes the root activity to be reactivated. The root activity issues a CHECK ACTIVITY command to see how D completed, and then completes normally, ending the process.
Note: For conciseness, some commands that could result in audit records being written - for example, PUT CONTAINER ACQPROCESS and SUSPEND - are omitted from the example.