An unhandled VMS exception simply writes the condition, signal arguments,
stack contents, and register dump to the standard output.  This is seldom
useful in production software, because:

    The user doesn't even notice the exception.
    Even if they do, they aren't aware of the implications.
    Even if they are, they don't know that they should copy the dump.
    Even if they do, they aren't quick enough.
    Even if they are, they don't remember to inform you.
    Even if they do . . .

        IT'S STILL NOT ENOUGH TO HELP YOU FIND THE BUG.

So i wrote a relatively simple condition handler to solve all of the problems
listed above.  It traps any status desired, captures the data described below
(some via $getjpi() and $getsyi() calls, some via a user-written system service
named HOLMES), and logs it to a file named HARDWARE_EXCEPTION.RPT (in the login
directory, if such is defined).  The data written out includes:

    process information
    ==========================================================================
        the original condition which caused the exception
        names (user, process, account, terminal)
        times (login, cpu)
        image filespec
        default directory
        privileges (current, default, authorized, image)
        quotas (limit, count)
        working set (default, quota, extent, peak)

    system information
    ==========================================================================
        names (node, architecture, hardware, hardware model)
        times (boot, current)
        VMS version
        free global pages
        free global sections

    call stack
    ==========================================================================
        PC of each frame
        registers for each frame
        arguments in each frame [1]

    open file information [2]
    ==========================================================================
        channel number
        access (section, read, write, exclusive)
        resultant filespec or full device name

    activated image information [2]
    ==========================================================================
        channel number
        imagename (maybe filename, maybe logical name)
        ident (from LINK command)
        creation date (from LINK command)
        current "installed" state (a.k.a. "known file" state) if applicable
        how linked (/debug, /traceback, /sysexe or sys.stb)
        global section major & minor idents
        virtual address range
        current patches if any (ECO numbers) [3]

    active timers information [2]
    ==========================================================================
        type (normal, system subroutine, wake entry) (repeat) (cpu-based)
        event flag number
        AST routine address
        request identification (also the AST parameter)
        expiration date/time

    active locks information [2]
    ==========================================================================
        lock id
        parent id (or zero)
        resource name (part printable, part binary . . . ugh)
        octal group number from UIC (or the word "system")
        access mode (user, super, exec, kernel)
        currently granted mode (nl, cr, pr, cw, pw, ex)
        currently requested mode (nl, cr, pr, cw, pw, ex)
        request state (granted, converting, waiting)
        value block contents (four unsigned longwords)

[1]  not very reliable on ALPHA machines
[2]  written to the file only if the HOLMES package (q.v.) is installed
[3]  not applicable on ALPHA machines, since there is no PATCH.EXE for them

Examples for each architecture are provided in the SAMPLE_AXP_EXCEPTION.RPT
and SAMPLE_VAX_EXCEPTION.RPT files.

It would be nice to take advantage of any images linked /TRACEBACK to mimic
that output --- including module names, function names, and line numbers ---
but I just don't have time to decipher the TBK files in the [Vxx.TRACE.LIS]
source listings.  Sorry, I would very much like to do this, but not yet.

Of course this makes life easier for the Technical Support employees; all of
the information about which images, versions, and patches are all nicely
written out for them to a single file automatically so that all they have
to do is download that one .RPT back to me.

I, too, find it incredibly useful when debugging an access violation or some
similar exception during development, because I now have each image's virtual
address range written down for me; a hex subtraction against the offending PC
and a quick offset against the addresses listed in the .MAP file, and I've
narrowed down the guilty instruction exactly, even in a dynamically-loaded
shareable image.

This directory contains the source code and option files for both images and
a sample program demonstrating a call.  There are two implementation methods
available:  a condition handler that you can establish directly named
HER_HandleException(), and a function your handler can call named
HER_ReportException().

ok
dpm
-- 
David P. Murphy          http://www.myths.com/~dpm/
systems programmer        ftp://ftp.myths.com
                         mailto:dpm@myths.com            (personal)
COGITO ERGO DISCLAMO     mailto:dmurphy@ac-tech.com          (work)