*PSSR - Error handling in RPG

Excellent! Nice to see an AS/400 programmer caring about error handling for a
change.

There are three major error handling techniques in RPG; do nothing and let the
default error handler take
control (that's the one which displays something like "Error occurred at line
1234 (C G D S)"), use resulting
indicators and TEST their status, or code automatic subroutines to handle
errors.

There are two possible subroutines; A file error subroutine (INFSR) and a
program error subroutine (*PSSR).
File error routines can be given any name but need to be associated with the
file. That is done on the
F-spec by using the INFSR keyword. The program error subroutine MUST be called
*PSSR and simply having it
declared in the program is enough for the RPG compiler to pass control to it
when an unmonitored (no
resulting indicator) exception occurs. Note that the *PSSR WILL NOT
automatically get control for I/O
exceptions however the *PSSR can be used for both purposes if you name the
*PSSR as the INFSR routine. Both
the file and program error routines can be invoked by EXSR e.g., EXSR *PSSR.

Now for the bad news: When the file and program error routines are invoked by
the RPG exception handler due
to an unmonitored exception it is done as an unconditional branch, a GOTO if
you will, rather than an EXSR.
This makes it very difficult to determine the return point. The return points
provided by RPG (*GETIN,
*DETC, etc) are parts of the cycle and are effectively targets for a GOTO from
the ENDSR statement in the
*PSSR. *GETIN is the start of the Get Input section of the logic cycle. It is
not possible to provide your
own branch points on the ENDSR statement.

Usually what one does is to use the error routines to gracefully exit the
program rather than try to recover.
However it may be possible to use the STATUS code fields in the INFDS or SDS
data structures to determine if
the error is recoverable and design logic into your program such that the *PSSR
can determine where it was
called from; a status flag of some sort which is tested and then an
unconditional branch is performed to the
appropriate section of the program. This is usually SO UGLY that I cannot
commit such an atrocity and mostly
send a nice screen to the user telling them why the program broke, send a
message to QSYSOPR, dump the
program, job, and joblog, and cleanly close down.

Russ Popiel wrote a book called "RPG Exception Handling" available from Duke
Press (News/400 Magazine) which
is fairly good.

Here is an extract from my template showing how this stuff is defined. Note
that the SDS is externally
described and has the fields #STSCD and #LFUST, etc. The DUMP subroutine is
the one which decides whether to
dump the program, joblog, job, etc. You would test the value of the DBFSTS or
DSPSTS fields in the *PSSR to
determine if the error was recoverable. A SELEC block with tests and GOTOs
would work (ugly but no other
choice)
***************************************************************************
FABC2 UF A E K DISK InfSR(*PSSR)
D*************************************************
C MOVE '12' KEY 2
C KEY CHAIN ABC2 90
C IF NOT%FOUND(ABC2)
C MOVE KEY VBID
C MOVE 'AAAAAA' VBNAME
C WRITE ABCR2
C ELSE
C UPDATE ABCR2
C ENDIF
C
C*************************************************
C EVAL *INLR = '1'
C *PSSR BEGSR
C RETURN
C ENDSR
***************************************************************************