Let's see. I'm a little rusty: Isn't it "Pop it on to the stack; and push it off"?

>>> Stan Sieler <[log in to unmask]> 08/04 12:27 PM >>>
Re:

> Actually they aren't in any domain.  :-)
> You should use try/recover for all.
> My documentation for XCODETRAP doesn't indicate it handles range errors.
>
> : I'd've heard of XCODETRAP in time, I'd've probably used that
>
> Bad..., if you are going to use any trap routine use what the Trap Handling
> Programmer's Guide documents:
> HPENABLTRAP/XARITRAP.
>
> One of them is range errors.
> In fact, you should call COBOLTRAP and see what COBOL does for you.

Trap handling isn't a simple proposition, unfortunately.

Traps basically fall into two categories:

   interrupts caused by an instruction (e.g., LDW with a bad address,
   or ADDT (add and trap upon some condition);

   software caused traps (e.g., STRWRITE noticing a problem, or
   GETPRIVMODE noticing that your process doesn't have PM).

Unfortunately, there is no one mechanism on MPE that will catch *all* kinds
of traps.

Some "instruction" traps are usually (note that word) catchable by
some or all of: try/recover, XARITRAP, XCODETRAP, and possibly other mechanisms.

Some "software caused" traps are usually (note that word again) catchable
by some of XSYSTRAP, XARITRAP, try/recover, and possibly other mechanisms.

There are some kinds of traps that try/recover will not be able to
handle, even though one would think it should.  E.g., a LDW with a bad address.
Why?  Because try/recover is implemented as a "cheap try, expensive recover"
(the other choice is "expensive try, cheap & reliable recover").  The "try"
does nothing, and costs nothing (well, it costs one or two cycles at the
end of the try block, as it jumps over the recover code).  The "recover" is
expensive (for non-local escapes, which are the kind we're discussing),
because it must search through the stack, looking for a covering try/recover
block.  But...that search can fail, if the stack has been corrupted.  This
could result in the "recover" code not being found (or, perhaps,
in inappropriate "recover" code being found!).

It would be nice if I could say:

   I don't care who I am, what I'm executing, or where I've been...
   if anything goes "wrong" from now until I tell you otherwise, I want
   you to call procedure "foo" first, before any other attempt at handling
   the trap...and if you can't do it, please abort my process.

But...we can't.  (Of course, there are a number of security problems in
implementing such a concept, but that's a different subject.)


Stan Sieler                                           [log in to unmask] 
www.allegro.com/sieler/wanted/index.html          www.allegro.com/sieler