On 04 May 2012 13:42, CRPence wrote:
On 04 May 2012 13:12, John Rusling wrote:
I gotta move on to something else, I don't really know what happened
but - (afawk its only happened this one time) -
Thanks for all the help, I gained more knowledge thru your efforts.
Might be worthwhile to add some more values to the DMPLST and\or add a
DFTPGM to the messages in the MCH0800 range; i.e. presume that if once,
then likely again. <<SNIP>>
Or either instead of or in addition to a DFTPGM, for whatever is the
/unexpected/ error condition and as-yet unknown error message that had
effected the CL run-time default [function check] exception handler
QCL_Function_Check_Exception_Handler to get invoked, change the code in
the failing EDPROC to add a MONMSG CPF9999 EXEC(DO). After that, add
code to effect whatever logging [e.g. DSPJOBLOG OUTPUT(*PRINT) perhaps
after an OVRPRTF QPJOBLOG SPOOL(*YES) HOLD(*YES) OUTQ(secure) to ensure
the user can not delete the spooled joblog] and any desirable
notification actions before a closing ENDDO. That will cause the MONMSG
EXEC handling for the failing statement\command to intercept the error;
instead of the run-time CL default handler. And given that the specific
error is still unmonitored, the DMPLST and DFTPGM processing are both
still allowed to occur as well. This change of course would enable
catching the unknown error even if that error is not one of the
presumed-to-be MCH0800 range of messages.
After stmt 64600 in the following:
EDPROC in WZZZJBL0 module EDPROC Procedure: EDPROC
After stmt 700 in the following; optional, because prior change
should render any change here moot; or just here, not the prior:
J55D0801 in WZZZJBL0 module J55D0801 Procedure: J55D0801
For additional reference, my comments here:
Subject: Re: system reply list entries
Date: Fri, 16 May 2008 12:51:18 -0500
http://archive.midrange.com/midrange-l/200805/msg00887.html
More generally however, with regard to the comment in the
original\opening post that "If our in-house log file hadn't revealed
this, we would have had no clue that anything was out of the ordinary",
the code may benefit from declaring its own Function Check Exception
Handler to effect desirable notification\logging; e.g. an entry in the
"in-house log file".
So possibly, rather than making the function check handler local to
the one request, the MONMSG CPF9999 EXEC(GOTO BadThing) could be a
global monitor. However that may not be compatible with the intentions
of that processing which "is setup so the program and job will keep
executing" according to a later message, because I do not recall that
the CL has been updated to allow a 'return from exception' capability.
Presumably GOTO is still the only allowed action in a global MONMSG,
thus attempts to react similar to how the 'I'=Ignore or 'R'=Retry of the
CPA0701 and CPA0702 function, is much more complicated than one might
desire trying to effect.
Some good reference reading:
IBM i 7.1 Information Center -> Programming -> Control language -> Messages
_i Monitoring for messages in a CL program or procedure i_
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/rbam6/monmg.htm
-> Monitoring for messages in a CL program or procedure
_i CL handling for unmonitored messages i_
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/rbam6/dfthd.htm
"The system provides default monitoring and handling of any messages you
do not monitor. ..."
Regards, Chuck
midrange.com
