MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » August 2014

Re: MCH0601 - I've no idea what's happening



fixed

On 08-Aug-2014 11:38 -0500, CRPence wrote:
<<SNIP>> I believe the RNX9999 implies the error was implicitly
handled in response to an unmonitored exception, and if so,

The above should have left the inquiry message name RNQ9999; there is apparently no equivalent 9999 RPG run-time error-condition identified with a RNX message identifier. The actual spooled joblog with full logging enabled would show if\what condition was unmonitored, and thus what could be captured accordingly.

the MCH0601 can be used to trigger an action [and should by default
the existing action would include spooled files QPDSPLOG and
QPSRVDMP being produced; wherein the former includes a stack and the
latter likely including some of the static storage identified by the
pointer, which I suppose would reveal the actual length and implying
the large offset was invalid due to being far past the end]. <<SNIP>>

That should have noted QPDSPJOB as the former SplF name, but that is somewhat moot, as the default action does not include the *JOB information for the Data To Be dumped (DMPLST) as defined for the MCH0601; apparently only some specific FMT() entries from the message are defined to be dumped when the error condition is not monitored. So if the condition was unmonitored and the Dump List information had the *JOB information-item added, then a new incident would have the spooled Display Job information included for review of\after the failure.






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