Dave wrote: >firstname.lastname@example.org 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, email@example.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: firstname.lastname@example.org * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.