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.
midrange.com
