Re: Catching errors on user screens

["Buck" <buck.calabro@xxxxxxxxxxxx>]

> >Generally, it would be enough for us if we could force a dump on each
> >error and send a message somewhere. There are only very few situations
where I
> >can continue the crashed program.
>
> When INFSR routines or the *PSSR are invoked as a result of an unexpected
error
> they are reached by a jump or branch or GOTO generated by the compiler.
That
> means you have no way of knowing how you reached the error handler and
therefore
> no way of knowing where you should return. Sometimes it is possible to
continue
> at *GETIN or branch to a known point in the program such as the start of
the
> main loop but mostly an error handler should just exit after collecting
> diagnostic information.
>
> The problem is not so much the use of GOTO but rather the lack of a
COMEFROM.

I completely agree with Simon.  I prefer my *PSSR to be the last chance for
error trapping, rather than actually handling the error and continuing.  To
see how nasty it can be to use *PSSR for recovery, see this thread in the
archives <http://archive.midrange.com/rpg400-l/200002/msg00234.html>

One thing I would be tempted to do is write an RPG program that modifies the
BPCS source to put an error indicator on all the I/O operations
(READ/WRITE/EXFMT/CHAIN, etc.) and a simple EXSR *PSSR to do the dump and
end the program.  Because it is an automated program, you could run it if
the BPCS code ever does get updated.

You can do an OVRDBF QRPGSRC MBR(*ALL) before running the 'error code
inserter' program, and then check the member name in the INFDS:
D MEMBER                129    138

Then you can process each member and when the member changes, compile it.

You may also be able to add MONITOR blocks if the source is RPG IV...
  --buck