Re: need for a new CPF catch MONMSG

On 13-Feb-2014 05:47 -0800, Hoteltravelfundotcom wrote:

Sorry if this is a little vague.

Being a CLP, they are generally simple enough to just post the [relevant] source; though what a writer deems /relevant/ may not match what the reader really needs, so posting the entire source [code.midrange.com is a place that can be utilized for posting of something more than snippets or otherwise small code examples].

I have a small CL that runs daily. It creates a temp file that I use
in the Reporting tool.
<<SNIP>> Anyway, I have the CPF0000 MONMSG on there but a couple of
weeks ago that file was in use in a diff view I was creating at that
moment so the job aborted.

Where the MONMSG CPF0000 is very pertinent; "on there" is meaningless information.

But it hung waiting for a response.

Hung on what? On the the CLP default handler; i.e. inquiry CPA0701 or CPA0702?

The problem with that is, that other jobs are stuck in the traffic
jam and if my manager had not noticed, they would not have run for
most of the evening.

Code the program to properly handle errors and to avoid whatever is the /hang/ condition.

In such a case, I would like the job to just quit, as the data is
not mission critical, it's just for a report that is run
occasionally.

If the /hang/ condition is the CL default handler inquiry, then ensure the job runs with Inquiry Message Reply Handling (INQMSGRPY) set to automatically send a default reply [INQMSGRPY(*DFT)] and ensure with system change management both that the default reply value does not get changed from C=Cancel and that the job is not changed externally to have that setting modified.

Perhaps someone knows which other MONMSG CPF I would add to that CL?
I can't have my jobs holding up others. In fact, this can cause the
system to not come up because of this.

The CPF0000 handles every condition including CPF9999; the latter covers any message with a prefix other than CPF.

If the issue is an error effected the CL default handler and its inquiry, then a very appropriate and simple resolution is to code a global MONMSG CPF0000 which will supersede the CL default handler which is coded with a EXEC(GOTO label-name). If the label has anything more than a RETURN statement, then every eligibl CL statement-command until the RETURN must have its own local MONMSG CPF0000 coded to avoid an exception ]recursion] loop.