Re: monitoring for java errors

On 26-Sep-2016 15:30 -0500, Chris Bipes wrote:

If you put a MONMSG with a CPF after a java command, your CLP will
not compile with an error about cannot monitor for CPFXXXX message.

That would be a defect. Any variation of text AZZ#### can be coded on the Message Identifier (MSGID) parameter; i.e. where the 'A' represents any one upper-case alphabetic, the 'ZZ' represents any combination of upper-case alphabetic and\or the decimal digits '0'to'9' and '####' represents any combination of four hexadecimal digits '0'to'9' and\or 'A'to'F'.

If you have a CLP source that does not compile, for which those requirements are met, then please share the source.

But monitor for the JVAXXXX message appears to work. Because the CPF
was returned to the CLP, that is what I was monitoring for. Not the
JVAXXXX.

As expected. But when the specific or generic JVA#### message is not monitored, then either of the generic CPF0000 message id or the specific CPF9999 message identifier can be specified to effect monitoring for the *FC. Coding either would prevent the default handler being invoked, and thus prevent the inquiry; NB that monitoring either of those will still leave the CPF9999 error logged [as seen in the joblog], but again, the overall effect will not include the inquiry.

A generic CPF0000 at the top of the CLP does not capture the JVA
error.

If that generic monitor is properly coded as global, then the effect of "does not capture", depending on how that expression is defined, could indicate a defect.

The noted generic monitor indeed would not /catch/ the JVA0122, but the monitor should necessarily prevent the inquiry, because the /default handler/ of the CL should not be invoked. That is because the monitor of the generic CPF0000 would include the capture of the CPF9999, aka the *FC, and that prevents the default handler from being invoked.

The two systems this is occurring on are both V7R2. The exact same
java program runs on V6R1 with no memory leaks. The difference in the
systems is the version of the JT400. The two V7R2 boxes have the
latest and greatest versions while the V6R1 systems are running the
appropriate version for them.
[…]

What my replies have attempted to address is unrelated to the memory problem; they are applicable only to the messaging and handling within the CLP. Albeit without some underlying issue generating the JVA0122, the Monitor Message plays no role. Specifically, I have concerns for the subject "monitoring for" the failed JAVA command. According to what I infer from the text quoted in this reply, and what I infer from what was written in the OP, seems possibly that the message monitoring feature could be functioning incorrectly; be that in compile-time and\or run-time.

The following CL source should compile on any release since at least as far back as v5r3; if run, the CL default handler should be invoked, and the inquiry message CPA0701 sent [or CPA0702 if compiled as CLLE vs CLP]:

pgm /* specific monitor against _randomly_ named msgid */
JAVA CLASS('/tmp/stuff/class.file.noexiste') +
CHKPATH(*IGNORE) OUTPUT(*PRINT)
monmsg M1P0ADD exec(*N)
endpgm

Each of the following CL sources should compile on any release since at least as far back as v5r3, and when called, should either spool a QPJOBLOG or present the DSPJOBLOG output when run interactively because the named class file [surely] does not exist; there should be no inquiry message sent in response to the effect of the Function Check that gets logged:

pgm /* monmsg for *fc after JAVA cmd */
JAVA CLASS('/tmp/stuff/class.file.noexiste') +
CHKPATH(*IGNORE) OUTPUT(*PRINT)
monmsg cpf9999 exec(goto jl)
return
jl: dspjoblog output(*)
endpgm

pgm /* generic CPF monitor after JAVA cmd; handles *FC */
JAVA CLASS('/tmp/stuff/class.file.noexiste') +
CHKPATH(*IGNORE) OUTPUT(*PRINT)
monmsg cpf0000 exec(goto jl)
return
jl: dspjoblog output(*)
endpgm

pgm /* global generic CPF monmsg; handles *FC */
monmsg cpf0000 exec(goto jl)
/* above is a Global MONMSG */
JAVA CLASS('/tmp/stuff/class.file.noexiste') +
CHKPATH(*IGNORE) OUTPUT(*PRINT)
/* No MonMsg for above rqs */
return
jl: dspjoblog
endpgm