RE: End users answering messages--Was RE: Open Source discussion on e rror handling was: RPGIII/RPG

Thats not what I am suggesting.

I was trying to say that you should trap all expected errors and let
*PSSR pick up the rest.
Then if an error occurs you show your error display 
"Error has occurred at statement ..blah blah blah, please report this
error to support dept etc,etc"
The program then exits in a controlled way, back to the previous program
or menu or whatever. It does not continue.
Then the user has the choice of reporting the error to you, trying
again, or getting on with something else.
But they do not get an OS/400 error message that they need to reply to,
because you catch all errors.

-----Original Message-----
From: Martin, Booth [mailto:BoothM@goddard.edu]
Sent: Monday, February 14, 2000 3:33 PM
To: 'RPG400-L@midrange.com'
Subject: RE: End users answering messages--Was RE: Open Source
discussion on e rror handling was: RPGIII/RPG


I will plead total ignorance here, so no one needs to point it 
out later on,
OK??

Is there a simple example program somewhere that shows what it 
is you are
suggesting with *PSSR?  In reading the manual it looks to me 
like you write
a subroutine for every possible error condition and name the subroutine
*PSSR. What use is that?  If you know the errors anyway, why 
not code for
them in the first place?  What part of the puzzle am I missing? 
 What good
is a catch-all subroutine that sets a bad array index back to 1 so
processing can continue?  That brings real meaning to "computers make
mistakes very accurately and very fast."


-----Original Message-----
From: Colin Williams [mailto:colin.williams@technocrats.co.uk]
Sent: Monday, February 14, 2000 4:07 AM
To: boothm@goddard.edu
Subject: RE: End users answering messages--Was RE: Open Source
discussion on e rror handling was: RPGIII/RPG


If your programs coded to expect errors, why should your users ever see
a message that they need to reply to. 
Any untrapped errors should be picked up by *PSSR and perform your error
processing.
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to 
RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: 
david@midrange.com
+---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---