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. 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.
A generic CPF0000 at the top of the CLP does not capture the JVA error. 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.
Also the java version are different:
V6R1:
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build pap32devifx-20150415 (SR16 FP10 ))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 OS/400 ppc-32 j9vmap3223-20150415 (JIT enabled)
J9VM - 20150323_240985_bHdSMr
JIT - 20130920_46470ifx2_r8
GC - 20141118_AA)
JCL - 20150415
V7R2:
java version "1.7.0"
Java(TM) SE Runtime Environment (build pap3270_27sr3fp50-20160720_02(SR3fp50))
IBM J9 VM (build 2.7, JRE 1.7.0 OS/400 ppc-32 jvmap3270_27sr3fp50-20160720_02 (JIT enabled, AOT enabled)
J9VM - R27_Java727_SR3_20160630_1516_B309914
JIT - tr.r13.java_20160629_120282
GC - R27_Java727_SR3_20160630_1516_B309914
J9CL - 20160630_309914)
JCL - 20160719_01 based on Oracle jdk7u111-b13
But the java application is the same package on all systems.
Chris Bipes
Director of Information Services
CrossCheck, Inc.
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Monday, September 26, 2016 1:05 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: monitoring for java errors
On 26-Sep-2016 09:32 -0500, Chris Bipes wrote:
I have a CLP that runs a java process. The java process will fail -
out of memory - (ok I am searching for the memory leak) but I want
to trap the error and loop back to run the process again. (Yes a band
aid).
The message is CPF9999:
"Message . . . . : Function check. JVA0122 unmonitored by
BBCSTART at statement 0000002900, instruction X'0000'. "
I tried to put a monmsg after the JAVA command but you cannot
monitor for that
What would "that" be? The JVA0122, the CPF9999, or perhaps an inquiry
message such as CPA0701? Another followup reply had already noted that,
to prevent the CPF9999 [aka *FC] from appearing, monitor for the error
message shown in the message text of the msg CPF9999.
The only other conspicuous value for "that" would seem to be the only
other message shown quoted above, and that is the CPF9999. But that
message *can be monitored*; and there are advantages in allowing for the
*FC to occur, in that the extra features Default Program To Call
(DFTPGM) and Data To Be Dumped (DMPLST) of Message Handler (MH) as
attributes defined in the Message Description (MSGD) [in this case, of
the msg JVA0122] would be activated.
So apparently what was not shown in the OP, i.e. the inquiry logged
in response to the *FC, is what /that/ "cannot monitor for".? And
indeed, only /exception/ type messages [i.e. *STATUS, *NOTIFY, and
*ESCAPE] can be monitored with the Monitor Message (MONMSG). Such an
inquiry would be the side effect of having failed to monitor for a
condition for which the effect was the Function Check (*FC); i.e. the
effect being that the /default exception handler/ of the HLL would have
been invoked, per lack of the user-code having included a monitor [and
optional handler].
so I added a global CPF0000 at the top of the CLP and it still went
to message wait. How can I monitor for JAVA errors within the CL that
starts the BCI?
Ah... that reference to a "Message Wait" (MSGW) status implies the
effect for what was not included in the OP; i.e. that there was a wait
on a reply from an inquiry.
However, the global monitor for CPF0000 *should have prevented* the
*FC from invoking the language's default handler. I would be concerned
if what is expressed just above is accurate; i.e. that the failed
request "still went to message wait" implies an apparent defect. Or
implies that the MONMSG was not really coded as the first /statement/ of
the CLP. Noting however, the CPF9999 would *still appear* [and the MH
would still invoke the /unmonitored exception/ capabilities], but there
should have been no inquiry message [because the default handler should
not have been invoked].
If the global handler is indeed verified to be non-functional, then
at what release\cumulative, and could the program source be shared for
review and test by someone at the same release to test for the same
improper effect?
midrange.com
