× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 13-Feb-2014 10:21 -0800, Peter Dow wrote:
<<SNIP>>

Another point is placement of the MONMSG CPF0000. If you put this
at the beginning of the program, it will apply globally to all
commands in the program; if you place it immediately after a
particular command, it will only apply to that command.

So if you really don't care whether the program completes
successfully, you can do a global MONMSG. Also, the ones I've seen
also ignore MCH0000.

Typically there is very little value in adding a global MONMSG MCH0000 when a MONMSG CPF0000 exists; esp. if they are coded on the same MONMSG or otherwise effect the same EXEC(). And worse, doing so may have undesirable consequences. Such examples of CL code ignoring [though hopefully most instead are trapping\catching the errors such that they EXEC(GOTO ...)] typically arise as a side effect of either a lack of understanding or a misunderstanding by the author, about the what and the how of the capabilities of the global monitor for CPF0000 [which could be CPF9999 instead]. If why either of the global monitors for CPF0000 or CPF9999 can be used to prevent the CL default handler from gaining control is not understood, then that is an indication that the added but most likely unnecessary and even probably undesirable monitor for the MCH0000 will appear; undesirable, for the effect of suppressing the Function Check (*FC) that is key to activating additional logging and handling support by the Message Handling component\feature.

But the better solution is to handle expected errors by monitoring
for them specifically and doing something appropriate.

Better to do both IMO. That is, local MONMSG(s) to handle expected errors, and the global monitor to handle unexpected errors... *if* the effect of the CL default handler [i.e. inquiry CPA0701 or CPA0702] is undesirable.

The _unexpected errors_ are for what the global monitor for CPF0000 [or CPF9999] provide value; i.e. avoids having to code a MONMSG CPF0000 after *every* [statement-]command that is eligible. Thus whatever was not specifically handled [be that due to something being overlooked or mis-coded, or simply to avoid source with a MONMSG following almost every line of code] can be intercepted and handled by the CL program instead of by the CL default handler.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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

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