The TRACE MANAGER collects all decentrally created component traces, a “trace” being defined as the collection of diagnostic information, during a session, at previously defined discrete locations in the system. This information consists of consecutive, individual records containing data specific to a component or the system, such as system status variables, program data, parameter lists, time stamps, etc. Traces are also saved when a dump is taken, thus improving the facilities for BS2000 system diagnosis as part of dump evaluation.
Traces may be performed locally (for a task) or globally (for the entire system). Consequently, the memory areas for storing the information (trace buffers) are located in either the task address space or the system address space. A local trace has a trace buffer and associated management data within each task. A global trace requires only one buffer and one set of management data for the entire system.
The TRACE MANAGER does not itself manage the trace buffers; it simply holds pointers to the buffers in its management tables. For this reason, the trace owners must inform the TRACE MANAGER of the size and location of the buffers. Since traces tend to generate large amounts of data in a very short time, the trace buffers are overwritten cyclically. The data in the buffers is saved using SLED or CDUMP and analyzed using DAMP.
In the course of a dump using CDUMP, the TRACE MANAGER generates the trace dump list (TDL), which contains buffer descriptors and selected trace description data (trace ID and the address of the next or last entry). The TRACE MANAGER cannot generate this list for a dump produced with the aid of SLED, since the operating system is no longer running after SLED has been loaded. In this case, the DAMP analysis program handles this task.
Figure 101: TRACE MANAGER functions
In the context of the central management of traces, various data is kept in tables under the control of the TRACE MANAGER. This data can be divided into three groups with different functions, which are kept in different tables. The management data comprises:
address lists,
operating data and
descriptive data.
The figure 102 shows how these data and tables are linked together.
The address lists form the basis of the management tables. The address list for global traces is anchored in the central BS2000 table XVT, while an address list for a local trace is anchored in the TCB of the relevant task. For each trace, the address list contains one fixed-length (8-byte) record which contains the address of the operational data block and a number of trace status flags. The address list is preceded by a list header containing the data describing the table, together with the address of the TDL.
Each defined trace receives an entry in the TDL, which includes, among other things, the address of the trace buffer, the name of the trace and the subsystem, and also the version of the subsystem.
Figure 102: TRACE MANAGER tables
The operational data block contains all the data which is required to access the trace buffer or the next free record in this buffer in the most efficient manner (buffer descriptors). The operational data block contains the address of the corresponding descriptive data block which is chained to the operational data block. This contains all the data needed for management by the TRACE MANAGER and for editing the trace buffer, such as the description of the trace buffer layout, the trace ID etc.
The global trace management tables are set up during the system startup phase: the TRACE MANAGER is called and initializes all the tables needed in connection with the management of global traces.
It is possible to define new traces dynamically and initialize them using the appropriate macros after the system has been started up. To do this, the trace management tables are passed a fixed-length dummy entry for every initialized trace, thus allowing new traces to be accepted (ïdynamically defined).
When setting up local trace management tables, the TRACE MANAGER is called by the base system each time a new task is created. Upon termination of the task, the TRACE MANAGER is called again, this time to release the local trace management tables.
During a system restart, the local task management tables are deleted and replaced by the tables stored at the time of the checkpoint.
Local task traces can also be dynamically defined and initialized after the system has been started up. The global system trace address list has spare entries for the local task traces. The memory required for the local task trace tables is initialized when the tables are installed.
It is also possible to suppress traces dynamically in the subsystem’s shutdown routine as well as to define traces dynamically.
In order to define a trace, the TRACE MANAGER requires information, which it stores in the global system management tables. This information can be passed to the TRACE MANAGER either statically (data is already available as code in the trace tables) or dynamically (using a macro).
The TRACE MANAGER is controlled via the following operator or system administrator commands. The commands are described in detail in the “Commands” manual [8].
Command | Description |
SHOW-TRACE-STATUS | Display information on system traces |
START-TRACE | Activate a trace |
STOP-TRACE | Deactivate a trace |
Table 22: Overview of the TRACE-MANAGER commands