|
midrange.com
Hello Derick,
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)
*------------------------------------------------------------------------
* F I L E D E C L A R A T I O N S
*------------------------------------------------------------------------
F DISK KINFDS DBFDS UC
F KINFSR *PSSR
F WORKSTN KINFDS DSPDS
F KINFSR *PSSR
*------------------------------------------------------------------------
* D A T A S T R U C T U R E D E C L A R A T I O N S
*------------------------------------------------------------------------
* File information feed back mapping - outfile
IDBFDS DS
I *STATUS DBFSTS
I B 156 1590RCDCNT
I B 397 4000RELREC
* File information feed back mapping - screen
IDSPDS DS
I H *STATUS DSPSTS
I 369 369 CFKEY
I B 370 3710CSR
I B 376 3770SFLRRN
I B 378 3790TOPRRN
* Program status data structure mapping
IPSDS ESDSPSDSP
/TITLE program name : description - *PSSR
---> CSR *PSSR BEGSR
* If we've been here before clear off
B1 C *INLR IFEQ $ON
<=== C RETRN
E1 C END *INLR = $ON
*
C SETON LR
C Z-ADD#STSCD STSCDE 50
C MOVEL#MSGID ERRMSG 7
* Go home
B1 C STSCDE IFGT 00000
*1 C #LFUST ORGT '00000'
<--- C EXSR DUMP
E1 C END STSCDE > 00001
<=== C RETRN
*
<--- CSR ENDSR *PSSR
Regards,
Simon Coulter.
//----------------------------------------------------------
// FlyByNight Software AS/400 Technical Specialists
// Phone: +61 3 9419 0175 Mobile: +61 0411 091 400
// Fax: +61 3 9419 0175 E-mail: shc@flybynight.com.au
//
// Windoze should not be open at Warp speed.
//--- forwarded letter -------------------------------------------------------
> X-Mailer: Internet Mail Service (5.5.1960.3)
> Date: Mon, 04 Jan 99 04:03:27 -0500
> From: "Derick A Lewis" <DERICKAL@india.mastech.com>
> To: MIDRANGE-L@midrange.com
> Reply-To: MIDRANGE-L@midrange.com
>
> Hi
>
> I am a beginner on AS400 and I need some tips on how to use error
> handling. I am trying to use *PSSR.
> For eg if I want to type a command on my screen and want to trap an
> error how do I go about doing it? I would like to use *PSSR and I know
> how to use RPG3. I would appreciate if the solution would be in RPG3.
> I want to get into the line after the error line in the program, after
> rectifing the error. I have tried using *GETIN but I am not sure if it
> is the right thing to do.
>
> Derick A. Lewis
>
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---
>
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
