Chuck,
Thanks for this level of detail.
The detailed joblog does not give any more information than I presented,
but your idea of checking for the specific member on the CHKOBJ resonates
and I think I'll add that. I'll bet that's what is happening. I am doing
the RTVMBRD for a specific named member so I should CHKOBJ for that same
member first.
Thanks for your help!
Rich Loeber - @richloeber
Kisco Information Systems
[1]
http://www.kisco.com
--------------------------------------------------------------------------
On 3/18/2013 12:51 PM, CRPence wrote:
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.
References
Visible links
1.
http://www.kisco.com/
midrange.com
