Here is the CLP:
PGM
DCL VAR(&JOB) TYPE(*CHAR) LEN(10)
DCL VAR(&TYPE) TYPE(*CHAR) LEN(1)
DCL VAR(&JOBNAME) TYPE(*CHAR) LEN(10) +
VALUE('BBAGENT')
/* had tried generic CPF0000 here with EXEC(GOTO CMDLBL(BATCH)) and it did not capture the error */
RTVJOBA JOB(&JOB) TYPE(&TYPE)
IF COND((&TYPE = '0') *AND (&JOB = &JOBNAME)) +
THEN(GOTO CMDLBL(BATCH))
SBMJOB CMD(CALL PGM(CUSTOM/BBCSTART)) JOB(&JOBNAME) +
JOBD(CUSTOM/BBAGENT) JOBQ(*LIBL/SERVER) +
PRTDEV(*JOBD) OUTQ(*JOBD) USER(*JOBD) +
PRTTXT(*JOBD) SYSLIBL(*SYSVAL) +
CURLIB(CUSTOM) INLLIBL(*JOBD) +
DSPSBMJOB(*NO) MSGQ(QSYSOPR)
GOTO CMDLBL(ENDPGM)
BATCH:
JAVA CLASS('com.shenmfg.AS400BBAgent') +
PARM('/usr/bin/bb/java/server.properties') +
CLASSPATH('/usr/bin/bb/java/bbas400.jar:/us+
r/bin/bb/java/jt400.jar') JOB(BBAGENTJVA) +
OUTPUT(*PRINT)
MONMSG MSGID(JVA0122) EXEC(GOTO CMDLBL(BATCH)) <<--- added this and it works. CPF does not compile if here
ENDPGM: ENDPGM
--
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 2:48 PM
To: midrange-l@xxxxxxxxxxxx
Subject: 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
Please contact support@xxxxxxxxxxxx for any subscription related questions.
midrange.com
