MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » February 2014

Re: need for a new CPF catch MONMSG



fixed

On 14-Feb-2014 07:01 -0800, Hoteltravelfundotcom wrote:
I don't have a message id I think the best thing is to create the
same situation again and get the message id.

Yet, knowing the actual message identifier and failing statement is not required in order to prevent the issue with the CL default handler intercepting control and sending an inquiry. If the important thing to do is to prevent a recurrence [IIRC the OP suggests the boss was unhappy about the CLP holding-up progress], then the /best/ thing to do may be to change\correct the code presently. Code a global monitor for CPF0000 or CPF9999 to effect a GOTO a label that is either a RETURN or a sequence of commands whereby each is followed by a MONMSG CPF0000 until the RETURN.

The specific issue that gave rise to the inquiry can be addressed later. Although there may still be sufficient information left on the system to discover that origin. Esp. so, if the inquiry CPA0701 [or CPA0702] was sent to QSYSOPR, because that means a copy should remain in the QHST log, and the inquiry reveals the failing MsgId and the failing statement number. In this way, both the specific issue and the lack of a global monitor can both be implemented as fixes. To be clear, even if the specific issue were to be prevented by adding a local monitor, then for lack of a global monitor, any issue that is overlooked or otherwise occurs unexpectedly, the inquiry for the default handler might just happen [and tick-off the boss] _again_ on some future invocation.






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact