...TRACE]000READ.ME
----------------
Program:	TRACETRAP.MAR
Author:		D.North, CCP
Date:		90.12.04
License:
    Ownership of and rights to these programs is retained by the author(s).
    Limited license to use and distrubute the software in this library is
    hereby granted under the following conditions:
      1. Any and all authorship, ownership, copyright or licensing
         information is preserved within any source copies at all times.
      2. Under absolutely *NO* circumstances may any of this code be used
         in any form for commercial profit without a written licensing
         agreement from the author(s).  This does not imply that such
         a written agreement could not be obtained.
      3. Except by written agreement under condition 2, source shall
         be freely provided with all executables.
      4. Library contents may be transferred or copied in any form so
         long as conditions 1, 2, and 3 are met.  Nominal charges may
         be assessed for media and transferral labor without such charges
         being considered 'commercial profit' thereby violating condition 2.

Warranty:
    These programs are distributed in the hopes that they will be useful, but
    WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
    or FITNESS FOR A PARTICULAR PURPOSE.

Description:
    TRACETRAP.MAR provides a programmer with a way to trap the output
    of an image's traceback dump (from the system TRACE facility) to a
    specified file, and to be called back after the trace dump is completed
    so that the calling program can "do" something with the file.  For example,
    the calling program may wish to use callable MAIL to send the dump
    somewhere.  This seems particularly applicable to detached processes.
    Granted, setting the process mode to dump seems to be the best way
    to get this information, but with the recent snafu about analimdmp.exe
    and system security, analyzing the dump may be impossible for some
    programmers.

Caveats:
    * This program works fine 'in the lab'.  There may be some strange
      behaviour under other conditions.  LIB$SIGNAL comes to mind for
      starters. (Of course, one could easily write an additional routine
      that could be called to flip trace trapping on or off for such calls...).
      Also, the routine is *not* supposed to tracetrap if the signal is not
      fatal to the image.  This is not absolutely proven.  The program is
      provided primarily as a starting point for the programmer requiring it,
      and not nearly so much as a finished product.  It really was just an
      experiment that turned out to look fairly useful.