Re: MCH3602 from QSYGRHLR?

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. What is the specific failing command-request; i.e. the full command-string for the failing Move Object (MOVOBJ)?

----------
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.

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

The naming of the program [Q, Security Component (SY), GR (Grant), Holder (HLR)] would seem to imply the operation is against an object type of *AUTHLR. I could imagine that the MODADR MI instruction might not be supported against that object type; there is an intrinsic relationship between a *FILE x/1901 and the *AUTHLR, but again, would seem more aligned with the MCH3603 "Pointer addresses object type not valid for this operation." than the msg MCH3602.?

This is running on 7.3.

Any ideas what might be causing this?

A defect in the OS code. Because there is a *FC, the system can be forced to dump the WRKJOB, the Job, and a VLog using the Data To Be Dumped (DMPLST) on the Change Message Description (CHGMSGD) so the next incident will provide additional logging:

chgmsgd mch3602 DMPLST(*JOB *JOBINT *JOBDMP)