Re: Eval Exception Error Trapping

Dave wrote:
>boldt@ca.ibm.com wrote:
>
>> 1) What do you normally do in a *PSSR?  Do you do more than
>>    DUMP and give the user a "submit an APAR" message?
>
>Most of the time, the graceful exit.  Currently use QMHMOVPM and return to the
>called cl program for it to display the message and send a message to the
"idiot"
>(me).
>
>> 2) If you return back into the program, where do you normally
>>    resume processing?  Also, how do you distinguish between
>>    expected and unexpected exceptions?
>
>Sometimes *GETIN or *DETL.  Of course, this is useless if program is not doing
rpg
>fixed cycle.
>
>> 3) In what situations would you use a *CONTINUE option on the
>>    ENDSR?
>>
>
>Like a divide overflow,  record locks,  receiver variable length not sufficient
>etc.    anybody heard of 10000.0001 and eval?  I am sure there are more
situations,
>but *CONTINUE leaves the control of the error in our hands.   *GETIN, *TOTC,
*DETL,
>*CANCL  etc. are just inflexible.  Give me the *CONTINUE and an updated PSDS on
the
>error and I can take care of myself.  PSDS does have some vague statement
number
>field available 8-)

OK, I think you confirmed my understanding of how *PSSR is
used.  As you say, currently, the *PSSR is best suited for
exiting your program gracefully.

You want control over exceptions?  The new MONITOR opcode
will be much better than *CONTINUE on the *PSSR for several
reasons.  Basically, you'll be able to monitor for specific
exceptions on specific operations.  Plus, the code to handle
the exception will be close to the statement that gets the
exception, so you don't have to go hunting through the
program to find the *PSSR.  MONITOR will provide much more
flexibility than a *CONTINUE option could.  In fact, as I
mentioned before, you could potentially do all exception
handling using only MONITOR.  (I would expect that *PSSR
will still be used for graceful exit from unexpected
exceptions, though.)

Here's another example of where MONITOR will be useful.
Currently, char to date conversion is coded using a TEST(DE)
followed by a MOVE.  This is inefficient since the MOVE
also validates the date.  Using MONITOR, you just do the
move, and if the date is bad, the ON-ERROR catches the
exception.  (That's another advantage of MONITOR!) Someone
else asked for more examples of the CF-Spec, so here's what
the code may look like:

     CF haveGoodDate = *off
     CF dou haveGoodDate
     CF    charDate = PromptForDate
     CF    monitor
     CF       dt = %date(charDate:*ymd)
     CF       haveGoodDate = *on
     CF    on-error 112
     CF       dt = *loval
     CF    endmon
     CF enddo

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the RPG/400 Discussion Mailing List!  To submit a new         *
* message, send your mail to "RPG400-L@midrange.com".  To unsubscribe   *
* from this list send email to MAJORDOMO@midrange.com and specify       *
* 'unsubscribe RPG400-L' in the body of your message.  Questions should *
* be directed to the list owner / operator: david@midrange.com          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *