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
