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?