Download Tivoli Workload Scheduler: Troubleshooting Guide

yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Chapter 4. In-Flight Trace facility for engine
Describes the tracing facility for troubleshooting the Tivoli Workload Scheduler
engine. This facility is called In-Flight Trace.
This document describes the Tivoli Workload Scheduler server tracing facility that
replaced Autotrace from version 8.6. The facility is designed to be used by IBM
Software Support, but is fully described here so that you understand how to use it
if requested to do so by IBM Software Support.
The Tivoli Workload Scheduler server tracing facility (hereafter called In-Flight
Trace) is a facility used by IBM Software Support to help solve problems in Tivoli
Workload Scheduler. At maximum capacity it can trace the entry into and exit from
every Tivoli Workload Scheduler function, plus many other events, and includes all
log and trace messages currently issued by the CCLog facility.
In-Flight Trace has been conceived as a multi-product tool, although this
description concentrates on its use for Tivoli Workload Scheduler.
It works as follows:
Existing trace calls
In-Flight Trace uses the logging and tracing facilities still used by the
CCLog logging and tracing mechanism, and which were used by the
Autotrace facility in releases before 8.6.
Function entry and exit
In addition, the Tivoli Workload Scheduler engine product build now
inserts trace calls in the code to record the entry to and exit from every
function and assigns a sequential numeric function ID to each function.
The trace calls use these IDs to identify the functions.
Building the xdb.dat symbols database
During the same process, the build creates the symbols database
associating the name of each function with the function ID. In this way, the
trace writes the minimum information possible to the trace record (the
function ID), which can then be expanded to give the function name later
for viewing.
The build also stores in the database the source file and line number of
each function.
Further, it stores the name of the component which "owns" the function.
One program contains many components, each of which contains many
The symbols database is the key to managing the activation/deactivation
and filtering of the traces. The information it contains is encrypted.
Tracing in shared memory
The traces are written to shared memory. This is divided into segments,
and the traces chosen to be written to each segment are written in an
endless loop. At maximum capacity (tracing all events on all functions) the
traces might loop every few seconds, while at minimum capacity (tracing
just one little-used function), the trace might not loop for months.
© Copyright IBM Corp. 2001, 2014