Re: MONMSG CLP Question

On 18 Mar 2013 10:30, Rich Loeber wrote:

The detailed joblog does not give any more information than I
presented,

Actually a spooled joblog does contain much more information that what was given. The context of the messages [from\to programs, procedures, statements\instructions, requests] is completely unknown without the joblog and\or trace.... without a very wordy message or very succinct symptom keyword strings that divulge the context of each message.

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.

Unfortunately the same window for the failure exists, even with adding the MBR(named) on the CHKOBJ. The problem with CHKOBJ is that there is little value for its use with concurrency, which is what the origin for the problem must be; i.e. the object deletion is occurring effectively /simultaneous/ to the failing RTVMBRD request. The result of a CHKOBJ is merely *historical* information, and therefore in a high-concurrency environment, that information is mostly irrelevant. Deferring the existence check to the RTVMBRD is actually the correct\proper thing to do when concurrent activity is possible; i.e. the CHKOBJ as prior work that will be repeated by the RTVMBRD would typically be labeled as an "overhead".

But because the RTVMBRD is what is the failing request, another resolution\circumvention is required. And reporting the issue as a probable defect is desirable, possibly to those who might have circumvented the issue in one or a few instances, but also to those who might not have encountered the issue yet.

As an attempt to circumvent the issue, I would actually replace the CHKOBJ with an ALCOBJ if having to deal with concurrency. However there is also the Retrieve Member Description (QUSRMBRD) API, which although probably coded much like RTVMBRD, may not experience the same issue in the same way that is negatively impacting the RTVMBRD request in the CLP; i.e. at least hopefully not signaling the *FC to the invoker, no matter what issues that API encounters.