Introduction to BTS audit trails
You can create an audit trail for the BTS processes and activities that run in your CICS® systems. You can use the audit trail to track the progress of complex business transactions and to diagnose problems in programs that are being developed to form a new business application.
- Trace entries are written to an internal trace table within the CICS address space. In contrast, the audit trail of a process is written to a CICS journal, which resides on an MVS log stream.
- Trace entries record the progress of tasks over a relatively short period, typically seconds, minutes, or hours. In contrast, the audit trail of a process can extend to days, weeks, or even months.
- Trace entries relate to activity in a single CICS region. In contrast, in a sysplex the execution
of different parts of a process might take place on different regions
within the sysplex. Therefore, each audit record contains system,
date, and time information. Typically, an audit record for a BTS activity
also contains:
- The identifier of the activity
- The process to which the activity belongs
- Information about the event which caused the activity to be invoked, canceled, suspended, or resumed; or that fired when it completed.
Because log streams can be shared by more than one region, it is possible to write audit records from different regions to the same log.
- None
- Process-level
- Activity-level
- Full.
- Filter records for specific process-types, processes, and activities
- Interpret records into a readable format.
You can use the CICS journal utility program, DFHJUP, to copy the audit log stream to a backup file and to delete the log stream. By editing the JCL used to run DFHATUP, you can make DFHATUP accept the backup file as input.
Audit records are buffered; they are written to the log stream only when the buffer is full or a sync point occurs. This means that, when multiple CICS regions share the same log stream, audit records might not be in exact date and time order.