Audit trail examples

Figure 55 shows the sequence of activations of a BTS process, SALES1234567890. The activities that make up the process run on two CICS® regions. For the sake of clarity, the example does not show the activations of any other processes that might also be running in these regions.

Figure 55. Example audit trails. The right-hand columns show, for each audit level setting, the points at which audit records would be written. The letters in these columns are the names of the activities for which records are being written.
 On the left of the picture are a number of boxes that represent the process and activities, described in the text, that run on system SYS1. In the centre of the picture are a number of boxes that represent the activities, described in the text, that run on system SYS2. On the right are four columns that 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 process’s root activity is activated, and when it completes. The "ACTIVITY" column contains all the letters in the "PROCESS" column, plus others for the root activity’s descendent activities--when they are activated and when they complete. The "FULL" column contains all the letters in the "ACTIVITY" column, plus others for the root activity’s descendent activities--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 child’s completion status. 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 by means of 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 the sake of brevity, some commands that could result in audit records being written--for example, PUT CONTAINER ACQPROCESS and SUSPEND--are omitted from the example.

Process-level auditing

A setting of PROCESS on the AUDITLEVEL attribute of a PROCESSTYPE definition specifies process-level auditing for processes of the defined type. Records are written from the audit points for processes.

If process-level auditing is set for the process in the example, only six records are written to the audit log (see Figure 55):

  1. When the process is defined
  2. When the process is requested to run
  3. When the root activity of the process is activated for the first time
  4. When the root activity of the process is activated for the second time
  5. When the root activity of the process is activated for the third time
  6. When the process completes.

Activity-level auditing

A setting of ACTIVITY on the AUDITLEVEL attribute of a PROCESSTYPE definition specifies activity-level auditing for processes of the defined type. Records are written from:

If activity-level auditing is set for the process in the example, the following records are written to the audit log:

Full auditing

A setting of FULL on the AUDITLEVEL attribute of a PROCESSTYPE definition specifies full auditing for processes of the defined type. Records are written from:

If full auditing is set for the process in the example, the following records are written to the audit log:

Note:
Full auditing has an adverse effect on performance. It is intended to provide the maximum amount of information to help track down problems when applications are being developed. It is not intended to be used on production systems.

Related concepts
Introduction to BTS audit trails
Related tasks
Specifying the level of audit logging
Audit trail constraints--using DASD-only logstreams
Using the audit trail utility program, DFHATUP
[[ Contents Previous Page | Next Page Index ]]