Re: MCH3602 from QSYGRHLR?

On 10-Aug-2016 13:38 -0500, CRPence wrote:

On 10-Aug-2016 13:15 -0500, David Gibbs wrote:

I've got a program on a customers system that's doing a MOVOBJ …
and, sometimes, it's failing with a MCH3602 error.

IBM is saying that it's our program that's at fault ... but I
can't see how. We're just invoking MOVOBJ with parameters.

You are correct; they are clearly wrong.

And BTW, there are examples of some APARs from the past, whereby in each case, the system program that exhibited the msg MCH3602 had "an uninitialized pointer" variable that was referenced, under the *assumption* that the pointer would have been initialized to *NULL, but instead the pointer by chance had a valid [but garbage-in\uninitialized] pointer value, and *luckily* the pointer-type was incorrect for the operation; I say luckily, because better to have a failure than to have a bad decision made by the code such that instead the experience is GIGO.

----------
MCH3602 Escape 40 08/02/16 07:18:24.278876
#cfochkr 0001C8 QSYGRHLR QSYS 0004
Message . . . . : Pointer type not valid for requested operation.
Cause . . . . . : A pointer type was not valid for the requested
operation.
Recovery . . . : Correct the pointer use.
CPF9999 Diagnostic 40 08/02/16 07:18:24.289705
QMHUNMSG *N QLIMVOBJ QSYS 03BA
Message . . . . : Function check. MCH3602 unmonitored by QSYGRHLR
at statement *N, instruction X'0004'.
----------

Symptoms keyword string:
msgMCH3602 f/#cfochkr t/QSYGRHLR
msgCPF9999 *FC t/QLIMVOBJ

The phrase "Pointer type" is significant, I'm sure. <<SNIP>>

I would expect a more likely exception of x2203 vs the x2202 in such
a scenario. <<SNIP>>

That should have noted x2403 vs the x2402. Similar to the former exception implying a mismatch in object-type, the latter exception implies a mismatch in pointer-type. For an program object, the request to issue a Destroy Space is disallowed because the object is not a space-object; that would be a case for the x2403. For a space pointer, a program can not invoke a procedure, because the pointer must be a procedure pointer; that would a case for the x2402.

I can not intuit what would be the expected pointer-type in QSYGRHLR, because I can not fathom why the program would ever have been invoked, nor can I infer what pointer or operation on that pointer that has failed. But the LIC program that issued the exception was the "Object Checker" [# effective OPM LIC ¿or would that be VLIC vs SLIC?, cf Common Function, o Object, chkr Checker]; just about any MI instruction for which the object-checker is invoked should be a System Pointer. So perhaps the pointer is a space pointer and the object checker diagnoses the x2402 rather than acting against the associated system-object, or the space pointer is to other than an object; e.g. teraspace storage. That the object checker was what issued the error, was what had me thinking originally, that the x2403 was more likely; perhaps the likelihood of the x2402 vs x2403 actually makes even more sense.