|
Hans, An example of when we use the *PSSR: In our entry/update programs we update data base files through EXCPT (which does not take an error indicator). Sometimes an update is rejected by the data base (e.g. a change to a field that is used as an alternate, unique index causes a duplicate record error). In the most recent versions of these programs the *PSSR is used to handle this exception. The *PSSR sets an indicator and returns to *DETL. Alas, this causes the main line to be somewhat messy. > 1) What do you normally do in a *PSSR? Do you do more than > DUMP and give the user a "submit an APAR" message? Set an indicator to inform the main line that it is going through error recovery instead of initialization; put the message ID of the error in the error text that will be shown to the user. > 2) If you return back into the program, where do you normally > resume processing? Also, how do you distinguish between > expected and unexpected exceptions? We return to *DETL; the main line skips initialization and redisplays the screen, with the error text. We do not distinguish between errors. > 3) In what situations would you use a *CONTINUE option on the > ENDSR? In those situations where we know an error might occur, but preventing it would be impractical. For instance: - Chances of data base errors are growing, with the expanding possibilities of putting constraints in the data base. Especially when adding constraints to an existing data base, it is good to know that existing programs won't bomb, when they violate a rule that was not known when they were created. - The infamous overflow. In commercial applications it is not very practical to make amount fields big enough to accommodate for the largest number times the highest price (would make printing invoices very interesting :-). That leads to code like: CF IF number * price <= Maximum_Value CF EVAL amount = number * price CF ELSE CF signal the error to the user CF ENDIF (assuming we have CF-specs, that is). Joep Beckeringh * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
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.