Re: monitoring for java errors

On 26-Sep-2016 17:04 -0500, Chris Bipes wrote:

Here is the CLP:

To be clear, not just my being pedantic, there is given only an apparent likeness thereof; i.e. what is given, is neither _the_ CLP source that failed to compile, nor _the_ CLP source with the actual global MONMSG for which run-time apparently did not operate properly.

As such, I would have to infer what might have been the actual source from the /words/ that attempt to explain, rather than having the actual source code\statements :-(

But, when I compile with what I infer to have been the actual source, there is no problem with either variation [across multiple releases] when using the message identifier CPF0000, neither with the compile nor run-time. Well, no problem other than, having been coded as such, whenever there is any exception that persists for each invocation of the JAVA command invocation, then there is a fast-loop on the exception. Per that effect, such /retry/ coding is generally a bad idea. But I infer from the OP that a /retry/ of the request is both expected to complete without error and that the JAVA invocation is long-running such that the effect of a fast-loop would not be seen [if each JAVA invocation takes time before failing vs failing nearly instantly] -- so that will not be a problem, at least not until that trap suddenly springs, and probably at the worst possible moment.

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 */

For the JVA0122 exception condition, a global monitor defined here as the MONMSG CPF0000 EXEC(GOTO CMDLBL(BATCH)) should have caught the CPF9999 exception [per the effect of the unmonitored JVA0122], and then directed the code to continue at the label BATCH; of course using that generic monitor to direct continuation anywhere other than some end-of-program processing or without first setting some "exit if I have been here before" escape-processing at that label is a very poor coding practice. Such a global monitor as retry should continue as a retry only for the specific [or some small set of generic] exceptions; in this case, probably just monitoring for the one message JVA0122 in the global monitor: MONMSG JVA0122 EXEC(GOTO CMDLBL(BATCH))

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 */

I would need the actual line of source that did not work. Does the compiler listing still exist with whatever was coded?

ENDPGM: ENDPGM

I suspect that if JVA0122 is replaced by CPF0000 as the only change to a copy of the above source, then the compile will complete without errors; i.e. what was thought to be the problem, was likely something else. I suspect that perhaps something as subtle as the font [or in my case, my eyesight] for which what is the actual problem diagnosed as msg CPD0753 sev-30 "Message identifier 'CPFO000' not valid." might not be immediately recognizable and possibly misinterpreted as an effect of /disallowing CPF messages/ in that context.