On 14-Nov-2015 12:02 -0600, Steinmetz, Paul wrote:
<<SNIP>> Any recommended CP* messages to monitor for? <<SNIP>>

IMO _no_ monitoring for messages should be the goal, for something expected to always function as-coded without any errors; i.e. allow the CL run-time default handler to be invoked if anything ever goes awry with anything presumed should _never_ fail.

Having done so allows seeing the error [if ever one occurs] upon review of that future failing scenario, to determine if that unknown error being diagnosed reflects an unexpected\abnormal failure that should never have transpired as was presumed-to-be appropriate, or might instead reflect an oversight such that the since-identified /normal/ error condition for which the CLP probably should be modified to include both a monitor and some specific error-recovery handling.

And FWiW, the Copy From Stream File (CPYFRMSTMF) feature suggests that the only error that can be monitored is CPFA095; an error for which the actual condition diagnosing the failure [presumably] will be a preceding diagnostic. About the only errors I can think of that would not be highly unexpected, would be something like "user profile storage exceeded" or "user not authorized". But again, IMO having those conditions fail with the default handler just as for any other, is far preferable to the errors being monitored and then handled; and especially preferable to the error be monitored but then ignored. Those two examples of failures, are not something from which the code can really /recover/ anyhow, by performing a simplistic error handling routine; I expect operator intervention is often most appropriate, and the CL\CLLE default handler inquiry, is a /good way/ to ensure such failures get notified to the operator.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 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].