RTS Tracing Using the Consolidated Tracing Facility (CTF)

This chapter provides details for enabling tracing of the COBOL runtime system (RTS). It gives a brief overview of the underlying Consolidated Tracing Facility (CTF) which the RTS uses to output trace information, and provides details for configuring which RTS events are to be traced.

In this Chapter

What is CTF?

The Consolidated Tracing Facility (CTF) is a tracing infrastructure which over time all components in the Server Express, Net Express, and Mainframe Express family of products will be enabled to use as their tracing mechanism.

In this release the following functionality is provided:

In future releases the following additional functionality is planned:

Enabling Tracing

Tracing is enabled via a configuration file which is identified to CTF by the environment variable MFTRACE_CONFIG. For example, on Windows:

set MFTRACE_CONFIG=e:\mydir\ctf.cfg

or on UNIX:

export MFTRACE_CONFIG=/home/mydir/ctf.cfg

The file identified by MFTRACE_CONFIG is a text file. Configuration information is specified as name-value pair entries with each entry on a separate line. Blank lines or lines beginning with ‘#’ are treated as comment lines. The file is processed during RTS initialization.

The following configuration entry types are provided:

mftrace.application

Restrict Tracing to a Specific Application

Syntax:
mftrace.application=application-name
Parameters:
application-namethe name of the application for which tracing is to be performed. This may be either a fully-qualified or unqualified name. If the application name is enclosed within parentheses, it will indicate that the application is being run under a trigger program such as run on Windows, or cobrun on UNIX, and that the second program of the command line is to be used as the real application name.
Default:

All applications will be traceable if mftrace.application is not set.

Comments:

mftrace.application is used to restrict tracing to a specific application. If the name of the application does not match application-name, all preceding configuration entries will be ignored and the remainder of the configuration file not processed.

Examples:
Restrict tracing to the myapp executable.
...
mftrace.application=myapp
...
Restrict tracing to the otherapp application being run under a trigger program
...
mftrace.application=(otherapp)
...
mftrace.comp.component-name#property

Set a Component Property

Syntax:
mftrace.comp.component-name#property=property-value
Parameters:
component-namethe name of the component for which the property is to be set.
property-namethe name of the component property to set.
property-valuethe value of the component property to be set.
Default:

The properties and their associated values depend on the component.

Comments:

mftrace.comp.component-name#property is used to set the property with the given name and value for the given component. Any property name and value can be set, irrespective as to whether the component will actually make use of it.

Multiple mftrace.comp.component-name#property entries may occur in the configuration file, but an entry which specifies a property for a component that has previously been set will cause the previous property value to be replaced.

Properties are intended to be used for defining the areas of tracing that are required for the component

Property names are case insensitive.

If any of the following well-known property case-insensitive values are used, they will be held in two forms: the string as given, and a corresponding numeric value.

String ValueNumeric Value
ON1
OFF0
YES1
Y1
NO0
N0
TRUE1
FALSE0
ENABLED1
DISABLED0
numeric-stringn
Examples:

Set the memory and pgmload properties for the mf.rts component.

...
mftrace.comp.mf.rts#memory=on
mftrace.comp.mf.rts#pgmload=enabled
...
mftrace.emitter.emitter-name#property

Setting an Emitter Property

Syntax:
mftrace.emitter.emitter-name#property=property-value
Parameters:
emitter-namethe name of the emitter for which the property is to be set.
property-namethe name of the emitter property to set.
property-valuethe value of the emitter property to be set.

Emitter names and property names are case-insensitive.

Default:

The properties and their associated values depend on the emitter.

Comments:

mftrace.emitter.emitter-name#property is used to set the property with the given name and value for the given emitter. Any property name and value can be set, irrespective as to whether the emitter will actually make use of it.

Multiple mftrace.emitter.emitter-name#property entries may occur in the configuration file, but an entry which specifies a property for an emitter that has previously been set will cause the previous property value to be replaced.

Property names are case insensitive.

If any of the following well-known property case-insensitive values are used, they will be held in two forms: the string as given, and a corresponding numeric value.

String ValueNumeric Value
ON1
OFF0
YES1
Y1
NO0
N0
TRUE1
FALSE0
ENABLED1
DISABLED0
numeric-stringn
Examples:

Set the trace file name, the number of backup files, and the maximum size of each file in the backup set for the textfile emitter.

...
mftrace.emitter.textfile#location=e:\logs
mftrace.emitter.textfile#file=mytrace.dat
mftrace.emitter.textfile#maxgeneration=3
mftrace.emitter.textfile#maxfilesize=200
...

This would potentially cause mytrace.dat, mytrace.dat.1, mytrace.dat.2, and mytrace.dat.3 to be created in the directory e:\mylogs. Each of these files would have a maximum size of 200kb.

mftrace.level

Specifying the Default Tracing Level

Syntax:
mftrace.level=trace-threshold-level
Parameters:
trace-threshold-levelone of the following case-insensitive values:
NONENo events are to be traced.
DEBUGAll events are traced. This produces the most verbose output.
INFOAll INFO, WARN, ERROR, and FATAL events are traced.
WARNAll WARN, ERROR, and FATAL events are traced
ERRORAll ERROR and FATAL events are traced
FATALOnly FATAL events are traced
Default:

mftrace.level=NONE

Comments:

mftrace.level is used to specify the default level of tracing that is to be performed by any component enabled for tracing. Multiple mftrace.level definitions may occur in the configuration file, but each occurrence’s level specification will replace the previous level specified.

Using mftrace.level.component entries it is possible to override this default tracing level for specified components (see mftrace.level.component-name - Specifying a Component’s Tracing Level).

Examples:

Set the INFO tracing threshold level

...
mftrace.level=info
...
mftrace.level.component-name

Specifying a Component’s Tracing Level

Syntax:
mftrace.level.component-name=trace-threshold-level
Parameters:
component-nameidentifies the component whose trace threshold level is to be set.
trace-threshold-levelone of the following case-insensitive values:
NONENo events are to be traced.
DEBUGAll events are traced. This produces the most verbose output.
INFOAll INFO, WARN, ERROR, and FATAL events are traced.
WARNAll WARN, ERROR, and FATAL events are traced
ERRORAll ERROR and FATAL events are traced
FATALOnly FATAL events are traced

Component names are case-insensitive.

Default:

If not set, a component’s trace threshold level is inherited from its parent, or the default trace level if the component does not have a parent.

Comments:

mftrace.level.component is used to specify the level of tracing that is to be performed by the given component, or any component that inherits from it. Multiple mftrace.level.component definitions may occur in the configuration file for the given component, but each occurrence’s level specification will replace the previous level specified.

Examples:

Set the WARN tracing threshold level for the mf.rts component. All other components will use the DEBUG tracing threshold level.

...
mftrace.level=debug
mftrace.level.mf.rts=warn
...

Configuring the TEXTFILE Emitter

The behavior of the TEXTFILE emitter and the format of the trace file it creates is controlled by the following properties:

Property Property Description Default
DelimChar The character used in the output file to delimit trace data parts for a trace event. space
File The name of the trace file to be written. The following pseudo-variables may be used for the construction of the trace file name:
  • $(APPNAME) - the base name of the executable invoked to start the current process. For example, if e:\nx40\base\bin\run.exe was invoked, $(APPNAME) would have the value of run.
  • $(EMITTER) - always textfile for this emitter·
  • $(GEN) - the generation of the file starting from 1.
  • $(PID) - the OS identifier for the current process
$(APPNAME).$(EMITTER).$(PID).log, or $(APPNAME).$(EMITTER).$(PID).log_$(GEN) if the MaxGeneration property has been specified. For example:
  • If the TEXTFILE emitter is being used to output trace events for run.exe executing as process-id 3456 and the MaxGeneration property has not been specified, the trace file created will be named run.textfile.3456.log
  • If the TEXTFILE emitter is being used to output trace events for myapp.exe executing as process-id 1975 and the MaxGeneration property has been set to 3, the trace files created will be named myapp.textfile.1975.log_1, myapp.textfile.1975.log_2, and myapp.textfile.1975.log_3.
FlushEvery A number indicating after how many trace records output the file will be flushed. 0 indicates that the file will never be explicitly flushed. 1
Format The format to be used for each trace data record written to the file. The following pseudo-variables may be used in the format specification:
  • $(COMPONENT) - the name of the component outputting the trace event.
  • $(DATA) - the trace data specified by the component to be output for the trace event. Each trace part will be delimited by the character specified by the DelimChar property.
  • $(DATE) - the current date output as yyyy/mm/dd·
  • $(EVENT) - the event identifier as specified by the component outputting the trace event
  • $(LEVEL) - the tracing level
  • $(TIME) - the current time output as hh:mm:ss.nnn·
  • $(THREAD) - the current thread identifier (Note this will be the OS thread id, not the COBOL RTS thread id)
$(TIME) $(COMPONENT) $(EVENT) $(LEVEL)$(DATA)
HexBlockSize A number that, when outputting binary trace data, specifies the number of hexadecimal bytes to be output in each block. Each block of hexadecimal characters will be separated by a '-' character. For example, if HexBlockSize is set to 4, and some binary trace data with the value 3132333435363738393A3B3C3D3E3F is specified for output, it would be formatted as follows:
31323334-35363738-393A3B3C-3D3E3F
8
Location The directory where the trace files are to be written. current directory
MaxFileSize The maximum size of the trace file in KB that will be written before the file is closed, and the next trace file in the generation sequence is opened. The first trace file in a generation sequence will result in the $(GEN) pseudo-variable (see File property above) being set to 1, the second in the sequence will result in it being set to 2, and so on until MaxGeneration is exceeded. Once the MaxGeneration number of files has been reached, the generation number will revert back to 1 and the first trace file in the generation overwritten. Only used if MaxGeneration > 1. 0x00002800, indicating 10 MB max file size
MaxGeneration The maximum number of trace files that will be written to while tracing is enabled. Used in conjunction with MaxFileSize. 1, indicating that only a single trace file will be created.
QuoteString Indicates whether string trace data is to be output enclosed in double-quote characters. true

Configuring RTS Tracing

Property Property Description Level Event Id Event Description
no property INFO 128 Start of RTS initialization
129End of RTS initialization
130Start of RTS deinitialization
131End of RTS deinitialization
132Entered COBOL container (Enterprise Server only)
133Exited COBOL container (Enterprise Server only)
254STOP RUN.
ERROR255RTS error
All--Enables/disables all of the other properties
ContainerEnterprise Server COBOL container eventsDEBUG43Server callback (start/finish)
46Service lookup callback (start/finish)
49Request handler function (start/finish)
INFO9Initializing environment for application running in the COBOL container (start/finish)
10Invoking application in the COBOL container (start/finish)
11Restoring initial state following the execution of an application in the COBOL container (start/finish)
25Request handler trace event
40Server initialization (start/finish)
41Server de-initialization (start/finish)
42Server context initialization (start/finish)
ERROR0Request handler “start/next request” error
1Request handler “response” error
2Request handler “end processing” error
3Error loading the main program of the application identified by the request handler “start/next request”
4Error loading the package containing the application identified by the request handler “start/next request”
5Syncpoint failure
12Application termination due to exit from Animator
ExternalExternal data eventsINFO26External data item created
27External data item destroyed
ERROR28External data item size mismatch
JSEMMVS Job Step Execution ManagerINFO44JSEM function entry
45JSEM function exit
MemoryMemory allocation and de-allocation eventsINFO13Memory allocated
14Memory freed
15Memory re-allocated (i.e. re-sized)
16Re-allocated memory freed
17Memory remaining allocated at RTS termination
47PL/I low-memory allocation (Mainframe Express only)
ERROR48Insufficient low-memory available for PL/I (Mainframe Express only)
MFPMMainframe Pointer Manager events (AMODE programs)INFO29Absolute memory registration
30External data registration
31Memory registration
32Working-storage memory registration
33External data de-registration
34Memory de-registration
35Working-storage memory de-registration
36Local-storage memory registration
37Local-storage memory de-registration
ERROR250MFPM error
PgmUser program entry, exit, chain, and link eventsINFO6Program entry
7Program exit
8Program chain
18Program link
PgmLoadProgram load eventsINFO19.int, .gnt, or .390 program load
20Logical cancel
21Physical cancel
22Logical cancelled program made live again
23DLL or shared object load
24DLL or shared object unload
38.lbr load
39.lbr unload
ERROR251Program load error
SignalSignal handling eventsERROR252Apply previously ‘held’ signal
253Signal caught
SysPgmSystem program entry, exit, chain, and link eventsINFO6Program entry
7Program exit
8Program chain
18Program link

The table above lists the properties that are available to control the output of events by the RTS component (its CTF component identifier is MF.RTS). The values associated with each of these properties are expected to be 0 or 1 (i.e. to switch off or on a functional area for tracing). The well-known aliases for 0 (off, no, n, false, or disabled), and 1 (on, yes, y, true or enabled) may also be used.

Windows Examples

By default, tracing is disabled for all components, so the bare minimum that is required to enable RTS tracing is for an mftrace.level or mftrace.level.mf.rts entry to be specified in the configuration file. For example, with the MFTRACE_CONFIG environment variable set as follows:

set MFTRACE_CONFIG=e:\mydir\ctf.cfg

and e:\mydir\ctf.cfg containing just the following statement:

mftrace.level=error

a trace file with an entry for event id 255 would be created by any process that generated an RTS error. Note that no properties for the MF.RTS need to be specified for this event to be emitted: simply having the trace level set to error is enough. See the no property entry in the table above.

In the examples that follow, the application mymain is used. This application is comprised of two programs: mymain.cbl and mysub.cbl.

mymain.cbl:

 identification division.
 program-id. mymain.
 environment division.
 data division.
 working-storage section.
 01 my-var pic 9(9) external.
 procedure division.
     move 1 to my-var

     perform 5 times
         call 'mysub'
         add 1 to my-var
     end-perform

     cancel 'mysub'

     call 'myprog'
     goback.

mysub.cbl:

 identification division.
 program-id. mysub.
 environment division.
 data division.
 working-storage section.
 01 my-var pic 9(9) external.
 procedure division.
     display my-var
     goback.

When mymain is executed, an RTS 173 error (“Program not found”) will occur for the call to myprog. The contents of a trace file generated using the configuration above will look something like:

1>   # -MFTRACE Text Emitter-
2>   # CommandLine      = mymain
3>   # ProcessId        = 2404
4>   # Date             = 2004/12/14
5>   # Time             = 11:54:42.875
6>   # Operating System = Windows XP Service Pack 1 (Build 2600)
7>   # Computer Name    = NWB-CPJDELL
8>   # Format           = $(TIME) $(COMPONENT) $(EVENT) $(LEVEL)$(DATA)
9>   11:54:42.875 MF.RTS 255 3 173 1 "myprog"

The entries marked 1> through 8> are header records output by the TEXTFILE emitter giving information about the application being traced. 8> indicates the format of the subsequent trace entries (this example is using the default trace entry format). The fields in entry 9> are therefore interpreted as follows:

11:54:42.875$(TIME)The time the trace entry was output
MF.RTS$(COMPONENT)The name of the component outputting the trace entry.
255$(EVENT)The event identifier (Event identifier 255 for the MF.RTS component indicates an RTS error)
3 $(LEVEL)The level:
0debug
1info
2warning
3error
4fatal
173 1 "myprog"$(DATA)Event specific data.

If the statement in the configuration file is now changed to specify a trace level of info:

mftrace.level=info

and mymain rerun, the trace file created will contain entries for the RTS initialization and de-initialization events in addition to the RTS error event. The trace file will look something like:

    # -MFTRACE Text Emitter-
    # CommandLine      = mymain
    # ProcessId        = 2820
    # Date             = 2004/12/14
    # Time             = 12:27:04.317
    # Operating System = Windows XP Service Pack 1 (Build 2600)
    # Computer Name    = NWB-CPJDELL
    # Format           = $(TIME) $(COMPONENT) $(EVENT) $(LEVEL)$(DATA)
    12:27:04.317 MF.RTS 128 1
    12:27:04.327 MF.RTS 129 1
    12:27:04.337 MF.RTS 255 3 173 1 "myprog"
    12:27:04.367 MF.RTS 130 1
    12:27:04.367 MF.RTS 131 1

To see which programs the application has invoked prior to the RTS error occurring, we need to set the PGM property. If we are also interested in where the programs have been loaded from and when they are cancelled we would also need to set the PGMLOAD property:

mftrace.level=info
mftrace.comp.mf.rts#pgm=true
mftrace.comp.mf.rts#pgmload=true

When mymain is rerun, the trace file created will contain additional entries for program load, entry, exit, and cancel events. The trace file will look something like:

    # -MFTRACE Text Emitter-
    # CommandLine      = mymain
    # ProcessId        = 4092
    # Date             = 2004/12/14
    # Time             = 13:44:30.868
    # Operating System = Windows XP Service Pack 1 (Build 2600)
    # Computer Name    = NWB-CPJDELL
# Format           = $(TIME) $(COMPONENT) $(EVENT) $(LEVEL)$(DATA)
    13:44:30.868 MF.RTS 128 1
    13:44:30.888 MF.RTS 129 1
    13:44:30.888 MF.RTS 19 1 0 0 "mymain" "" ""
    13:44:30.888 MF.RTS 6 1 17 0 "mymain"
    13:44:31.008 MF.RTS 19 1 0 0 "mysub" "gnt" "E:\myprogs"
    13:44:31.008 MF.RTS 6 1 1 0 "MYSUB"
    13:44:31.008 MF.RTS 7 1
    13:44:31.008 MF.RTS 6 1 1 0 "MYSUB"
    13:44:31.008 MF.RTS 7 1
    13:44:31.008 MF.RTS 6 1 1 0 "MYSUB"
    13:44:31.008 MF.RTS 7 1
    13:44:31.008 MF.RTS 6 1 1 0 "MYSUB"
    13:44:31.008 MF.RTS 7 1
    13:44:31.008 MF.RTS 6 1 1 0 "MYSUB"
    13:44:31.008 MF.RTS 7 1
    13:44:31.008 MF.RTS 20 1 0 0 "mysub"
1>  13:44:31.008 MF.RTS 6 1 1 0 "MYSUB"
    13:44:31.008 MF.RTS 7 1
    13:44:31.139 MF.RTS 255 3 173 1 "myprog"
    13:44:31.199 MF.RTS 130 1
    13:44:31.199 MF.RTS 20 1 0 0 "mymain"
2>  13:44:31.199 MF.RTS 6 1 17 0 "mymain"
    13:44:31.199 MF.RTS 7 1
    13:44:31.199 MF.RTS 131 1

The entries marked 1> and 2> show event type 6 and 7 entries (program entry and exit) for a program immediately after an event type 20 entry (logical cancel) for the same program. This can be explained by the fact that the checker embeds a cancel routine in all programs to close any files that the program may have opened. These cancel routines are implicitly invoked by the RTS as part of a logical cancel operation.

To enable the tracing of all RTS events with the exception of the memory management ones the configuration file entries would be:

mftrace.level = info
mftrace.comp.mf.rts#all=true
mftrace.comp.mf.rts#memory=false

When mymain is rerun, the trace file created will contain additional entries for external data items. If the programs had been compiled with the AMODE directive, there would also be entries for each of the MFPM events. The trace file will look something like:

    # -MFTRACE Text Emitter-
    # CommandLine      = mymain
    # ProcessId        = 2716
    # Date             = 2004/12/14
    # Time             = 14:33:22.704
    # Operating System = Windows XP Service Pack 1 (Build 2600)
    # Computer Name    = NWB-CPJDELL
    # Format           = $(TIME) $(COMPONENT) $(EVENT) $(LEVEL)$(DATA)
    14:33:22.704 MF.RTS 128 1
    14:33:22.714 MF.RTS 129 1
    14:33:22.714 MF.RTS 19 1 0 0 "mymain" "" ""
    14:33:22.714 MF.RTS 6 1 17 0 "mymain"
1>  14:33:22.714 MF.RTS 26 1 "MY_VAR" 9
    14:33:22.714 MF.RTS 19 1 0 0 "mysub" "gnt" "E:\myprogs"
    14:33:22.724 MF.RTS 6 1 1 0 "MYSUB"
    14:33:22.724 MF.RTS 7 1
    14:33:22.724 MF.RTS 6 1 1 0 "MYSUB"
    14:33:22.724 MF.RTS 7 1
    14:33:22.724 MF.RTS 6 1 1 0 "MYSUB"
    14:33:22.724 MF.RTS 7 1
    14:33:22.724 MF.RTS 6 1 1 0 "MYSUB"
    14:33:22.724 MF.RTS 7 1
    14:33:22.724 MF.RTS 6 1 1 0 "MYSUB"
    14:33:22.724 MF.RTS 7 1
    14:33:22.724 MF.RTS 20 1 0 0 "mysub"
    14:33:22.724 MF.RTS 6 1 1 0 "MYSUB"
    14:33:22.724 MF.RTS 7 1
    14:33:22.724 MF.RTS 255 3 173 1 "myprog"
    14:33:22.764 MF.RTS 130 1
    14:33:22.764 MF.RTS 20 1 0 0 "mymain"
    14:33:22.764 MF.RTS 6 1 17 0 "mymain"
    14:33:22.764 MF.RTS 7 1
2>   14:33:22.764 MF.RTS 27 1 "MY_VAR"
    14:33:22.764 MF.RTS 131 1

The entries marked 1> and 2> show the additional entries for external data items.

UNIX Examples

By default, tracing is disabled for all components, so the bare minimum that is required to enable RTS tracing is for an mftrace.level or mftrace.level.mf.rts entry to be specified in the configuration file. For example, with the MFTRACE_CONFIG environment variable set as follows:

export MFTRACE_CONFIG=/home/mydir/ctf.cfg

and /home/mydir/ctf.cfg containing just the following statement:

mftrace.level=error

a trace file with an entry for event id 255 would be created by any process that generated an RTS error. Note that no properties for the MF.RTS need to be specified for this event to be emitted: simply having the trace level set to error is enough. See the no property entry in the table above.

In the examples that follow, the application mymain is used. This application is comprised of two programs: mymain.cbl and mysub.cbl.

mymain.cbl:

 identification division.
 program-id. mymain.
 environment division.
 data division.
 working-storage section.
 01 my-var pic 9(9) external.
 procedure division.
     move 1 to my-var

     perform 5 times
         call 'mysub'
         add 1 to my-var
     end-perform

     cancel 'mysub'

     call 'myprog'
     goback.

mysub.cbl:

 identification division.
 program-id. mysub.
 environment division.
 data division.
 working-storage section.
 01 my-var pic 9(9) external.
 procedure division.
     display my-var
     goback.

When mymain is executed, an RTS 173 error (“Program not found”) will occur for the call to myprog. The contents of a trace file generated using the configuration above will look something like:

1>   # -MFTRACE Text Emitter-
2>   # CommandLine      = mymain
3>   # ProcessId        = 442550
4>   # Date             = 2005/01/21
5>   # Time             = 11:19:44.498
6>   # Operating System = AIX 5.1
7>   # Computer Name    = asterix
8>   # Format           = $(TIME) $(COMPONENT) $(EVENT) $(LEVEL)$(DATA)
9>   11:19:44.498 MF.RTS 255 3 173 1 "myprog"

The entries marked 1> through 8> are header records output by the TEXTFILE emitter giving information about the application being traced. 8> indicates the format of the subsequent trace entries (this example is using the default trace entry format). The fields in entry 9> are therefore interpreted as follows:

11:19:44.498$(TIME)The time the trace entry was output
MF.RTS$(COMPONENT)The name of the component outputting the trace entry.
255$(EVENT)The event identifier (Event identifier 255 for the MF.RTS component indicates an RTS error)
3 $(LEVEL)The level
0debug
1info
2warning
3error
4fatal).
173 1 "myprog"$(DATA)Event specific data.

If the statement in the configuration file is now changed to specify a trace level of info:

mftrace.level=info

and mymain rerun, the trace file created will contain entries for the RTS initialization and de-initialization events in addition to the RTS error event. The trace file will look something like:

    # -MFTRACE Text Emitter-
    # CommandLine      = mymain
    # ProcessId        = 1646624
    # Date             = 2005/01/21
    # Time             = 11:28:09.105
    # Operating System = AIX 5.1
    # Computer Name    = asterix
    # Format           = $(TIME) $(COMPONENT) $(EVENT) $(LEVEL)$(DATA)
    11:28:09.105 MF.RTS 128 1
    11:28:09.135 MF.RTS 129 1
    11:28:09.225 MF.RTS 255 3 173 1 "myprog"
    11:28:09.226 MF.RTS 130 1
    11:28:09.226 MF.RTS 131 1

To see which programs the application has invoked prior to the RTS error occurring, we need to set the PGM property. If we are also interested in where the programs have been loaded from and when they are cancelled we would also need to set the PGMLOAD property:

mftrace.level=info
mftrace.comp.mf.rts#pgm=true
mftrace.comp.mf.rts#pgmload=true

When mymain is rerun, the trace file created will contain additional entries for program load, entry, exit, and cancel events. The trace file will look something like:

    # -MFTRACE Text Emitter-
    # CommandLine      = mymain
    # ProcessId        = 1622058
    # Date             = 2005/01/21
    # Time             = 11:30:27.441
    # Operating System = AIX 5.1
    # Computer Name    = asterix
    # Format           = $(TIME) $(COMPONENT) $(EVENT) $(LEVEL)$(DATA)
    11:30:27.441 MF.RTS 128 1
    11:30:27.451 MF.RTS 129 1
    11:30:27.452 MF.RTS 19 1 0 0 "mymain" "" ""
    11:30:27.510 MF.RTS 6 1 17 0 "mymain"
    11:30:27.513 MF.RTS 19 1 0 0 "mysub" "gnt" "/home/myprogs"
    11:30:27.513 MF.RTS 6 1 1 0 "MYSUB"
    11:30:27.513 MF.RTS 7 1
    11:30:27.513 MF.RTS 6 1 1 0 "MYSUB"
    11:30:27.513 MF.RTS 7 1
    11:30:27.513 MF.RTS 6 1 1 0 "MYSUB"
    11:30:27.513 MF.RTS 7 1
    11:30:27.513 MF.RTS 6 1 1 0 "MYSUB"
    11:30:27.513 MF.RTS 7 1
    11:30:27.513 MF.RTS 6 1 1 0 "MYSUB"
    11:30:27.513 MF.RTS 7 1
    11:30:27.513 MF.RTS 20 1 0 0 "mysub"
1>  11:30:27.513 MF.RTS 6 1 1 0 "MYSUB"
    11:30:27.513 MF.RTS 7 1
    11:30:27.515 MF.RTS 255 3 173 1 "myprog"
    11:30:27.515 MF.RTS 130 1
    11:30:27.515 MF.RTS 20 1 0 0 "mymain"
2>  11:30:27.515 MF.RTS 6 1 17 0 "mymain"
    11:30:27.515 MF.RTS 7 1
    11:30:27.516 MF.RTS 131 1

The entries marked 1> and 2> show event type 6 and 7 entries (program entry and exit) for a program immediately after an event type 20 entry (logical cancel) for the same program. This can be explained by the fact that the checker embeds a cancel routine in all programs to close any files that the program may have opened. These cancel routines are implicitly invoked by the RTS as part of a logical cancel operation.

To enable the tracing of all RTS events with the exception of the memory management ones the configuration file entries would be:

mftrace.level = info
mftrace.comp.mf.rts#all=true
mftrace.comp.mf.rts#memory=false

When mymain is rerun, the trace file created will contain additional entries for external data items. If the programs had been compiled with the AMODE directive, there would also be entries for each of the MFPM events. The trace file will look something like:

    # -MFTRACE Text Emitter-
    # CommandLine      = mymain
    # ProcessId        = 1073210
    # Date             = 2005/01/21
    # Time             = 11:33:52.015
    # Operating System = AIX 5.1
    # Computer Name    = asterix
    # Format           = $(TIME) $(COMPONENT) $(EVENT) $(LEVEL)$(DATA)
    11:33:52.015 MF.RTS 128 1
    11:33:52.031 MF.RTS 129 1
    11:33:52.032 MF.RTS 19 1 0 0 "mymain" "" ""
    11:33:52.090 MF.RTS 6 1 17 0 "mymain"
1>  11:33:52.091 MF.RTS 26 1 "my_var" 9
    11:33:52.093 MF.RTS 19 1 0 0 "mysub" "gnt" "/home/myprogs"
    11:33:52.093 MF.RTS 6 1 1 0 "MYSUB"
    11:33:52.093 MF.RTS 7 1
    11:33:52.093 MF.RTS 6 1 1 0 "MYSUB"
    11:33:52.093 MF.RTS 7 1
    11:33:52.093 MF.RTS 6 1 1 0 "MYSUB"
    11:33:52.093 MF.RTS 7 1
    11:33:52.093 MF.RTS 6 1 1 0 "MYSUB"
    11:33:52.093 MF.RTS 7 1
    11:33:52.093 MF.RTS 6 1 1 0 "MYSUB"
    11:33:52.093 MF.RTS 7 1
    11:33:52.093 MF.RTS 20 1 0 0 "mysub"
    11:33:52.093 MF.RTS 6 1 1 0 "MYSUB"
    11:33:52.094 MF.RTS 7 1
    11:33:52.095 MF.RTS 255 3 173 1 "myprog"
    11:33:52.096 MF.RTS 130 1
    11:33:52.096 MF.RTS 20 1 0 0 "mymain"
    11:33:52.096 MF.RTS 6 1 17 0 "mymain"
    11:33:52.096 MF.RTS 7 1
    11:33:52.096 MF.RTS 41 1 0
    11:33:52.096 MF.RTS 41 1 1
2>   11:33:52.096 MF.RTS 27 1 "my_var"
    11:33:52.096 MF.RTS 131 1

The entries marked 1> and 2> show the additional entries for external data items.