User Application Information
This support interacts heavily with the Event Services.
- Because the trace table is kept as signals through Event Services instead of as a contiguous area of storage reserved for trace information, the Dump Viewing Facility should be used to look at the trace entries.
- The wrapsize specified on the TraceControl function is
for signals with no eligible monitor (loose signals). For monitored
trace signals, the bound signal limit constitutes a wrapsize for the
trace entries being monitored by that monitor. The signals kept in
loose signal wrapsize do not overlap with the signals kept in any
bound signal wrapsize.
As a result of this setup, there are potentially an unlimited number of conceptual trace tables, one for each eligible monitor and one for unmonitored trace events. By specifying different wrapsizes for each monitor and with TraceControl, the trace tables can be biased. For example, if one wishes to keep the last two dispatch entries, the last 20 communication entries, and the last 10 of any other type of entry, one would do the following:
- Issue TraceControl with a wrapsize of 10
- Monitor dispatch trace entries with a bound signal limit of 2
- Monitor communication entries with a bound signal limit of 20.
Note that this does not require that any of these entries be processed. It only determines the trace entries that CMS keeps in storage.
- Although the conceptual trace table created by TraceControl does not overlap with the conceptual trace table created by a monitor, two or more monitors may have overlapping trace tables. That is, more than one copy of a given trace signal may exist, depending on the number of monitors to which a given signal is bound. Although no processing is required of bound signals, this capability lets a trace entry be both processed and kept in storage. This is accomplished by having two monitors of a selected trace entry, one monitor that has an EventWait, EventTrap, or EventTest associated with it, and one monitor that does not.
- Allowing trace entries to be processed in real time is potentially
an extremely powerful capability. Although trying to list all the
new possibilities is impossible, here are a few examples just to give
an idea of this power.
- Writing selected trace data to a real file system
- Sending selected trace data from one virtual machine to another for processing
- Sending selected trace data from several virtual machines to another for processing
- Sending selected trace data from several virtual machines to another real machine (a workstation perhaps) for processing
- Monitoring processes' use of resources for simple tracking
- Monitoring processes to adjust thread and process dispatching priority
- User exit processing
- Debugging exit processing.