Browse Prior Art Database

Distributed Trace: A Facility to Trace Data and Code Flows In a Requester/ Server Environment

IP.com Disclosure Number: IPCOM000121541D
Original Publication Date: 1991-Sep-01
Included in the Prior Art Database: 2005-Apr-03
Document File: 3 page(s) / 121K

Publishing Venue

IBM

Related People

Garrison, J: AUTHOR [+4]

Abstract

The current trace facility for OS/2* EE is quite limited. Distributed trace overcomes this by allowing as much data to be traced as necessary, a trace buffer as large as the hard disk, remote management of the trace information, and combining traces from multiple machines.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 50% of the total text.

Distributed Trace: A Facility to Trace Data and Code Flows In a Requester/
Server Environment

      The current trace facility for OS/2* EE is quite limited.
Distributed trace overcomes this by allowing as much data to be
traced as necessary, a trace buffer as large as the hard disk, remote
management of the trace information, and combining traces from
multiple machines.

      Distributed trace (DT) is a set of functions which allows the
user to:
   1) Turn trace on or off locally and remotely.
   2) Query the distributed trace state.
   3) Trace (probe) data and control flow.
   4) Format the trace data in any user-definable format (this is the
subject of following article).
   5) Extract formatted data from one or more machines and place it
in one file.

      These functions are placed in a DLL file (for OS/2), and a
static library file (for other operating systems). Operating
system-dependent features (such as shared memory and semaphore
control) have been captured in a set of operating system routines
which have already been written for OS/2, DOS and AIX*.

      Since the DT functions and data are self-contained, the
distributed trace functionality can be used by almost any
program/system which wishes to use it.  It is not tied to OS/2 EE
Database Manager (for which it was written).

      Each of the above functions need to be explained in depth:
      1)   The overall philosophy of distributed trace is as follows.
A system administrator should be able to turn distributed trace on or
off either locally or remotely from any workstation on the network.
On each workstation, distributed trace keeps track of all processes
which are connected to remote workstations. For each of those
conversations distributed trace can be turned on either locally,
remotely, at both or at neither. Distributed trace insures that both
sides of a conversation know the state of distributed trace for that
conversation. In addition, the distributed trace system can keep
track of states on a node basis.  In other words, a system
administrator may turn distributed trace on (or off) with all
conversations to a remote node.  This affects all current
conversations with that node, as well as all future connections that
may be started with that node.
           The state of distributed trace may be changed as many
times as needed.  Each time it is changed, however, the previous
state is lost.  So the state of distributed trace for a conversation
is the result of the last change of the state.
           The state of distributed trace may be changed either from
the command line (a program provided by distributed trace), or by an
application program (via a supplied API).
           The only information that DT sends over the network at run
time is changes to the state of DT on each of the machines on the
network.  The actual trace data is left on each individual machine
(until extract time).  This gr...