Re: MONMSG CLP Question

On 18 Mar 2013 09:26, Rich Loeber wrote:

I have a CLP with a CHKOBJ for a specific *FILE object

By request to CHKOBJ MBR(*NONE), thus checking only the existence of the *FILE object? Anything other than MBR(*NONE) will test for the existence of the *MEM [aka *MBR] object [as well].

followed by a RTVMBRD statement for the same file.

If the next request will be RTVMBRD to a known member name, the prior CHKOBJ could include that member name. The CHKOBJ could even be replaced instead with ALCOBJ which would prevent the /deleted/ issue noted below.

Immediately after this statement, I have a MONMSG for a MCH3402
just in case the *FILE object is deleted between when the CHKOBJ
and RTVMBRD happen.

Only OS code should need to monitor for the x2202 condition in that case. If the *FILE goes missing, there is no stored pointer in the CLP, thus the CLP should never experience a condition which diagnoses that its resolved pointer points to an object that no longer exists.

The problem is that when this actually does happen, the MONMSG
seems to be ignored.The CLP throws the MCH3402 immediately
followed by a CPF9999.

The spooled joblog taken with LOGCLPGM(*YES) active and LOG(4 0 *SECLVL) will reveal better what transpired than a description such as that above.

When I look at the help text for the RTVMBRD, neither the
MCH3402 or the CPF9999 are listed as errors that can be
monitored for.

There are a variety of types of RTVMBRD invocations. Was this defaulting to MBR(*FIRST), asking for *LAST, *LASTMBR, *FIRSTMBR, or something else like generic and\or relative processing?

The MCH3402 should not be signaled to the requester of RTVMBRD. The CPF9999 is more likely to have been a failure to monitor for whatever was the failure, but there is also the chance that the RTVMBRD itself failed with CPF9999 and that was just resent\re-signaled to the invoker. Again, the spooled joblog tells a better story than what can be described in words.

Anyone ever run into this?

Most likely there is a defect, although depending on the type of invocation for RTVMBRD, I could imagine that some issues would not be corrected in a timely fashion or possibly ever.

Would changing the MONMSG to watch for CPF9999 do the trick?

While that could very likely prevent the problem from being manifest in a failure for the CLP, there may be better circumventions. Seeing the joblog is the first step to being better able to understand what is really going on in the failing scenario [with the CLP requests, if they do not appear as logged request messages]. The CLP for its MONMSG is probably worthwhile also, to correlate to the activity in the joblog, since monitors are not logged; or the given description can be assumed to be complete.