Re: MCH3602 from QSYGRHLR?

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

<<SNIP>> The naming of the program QSYGRHLR [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.? <<SNIP>>

Not to imply that there is any legitimate cause for the program QSYGRHLR to have been invoked for any of the failing Move Object (MOVOBJ) requests, but I should have mentioned nonetheless, that the command Display Authority Holders (DSPAUTHLR) is about the only /visibility/ to those objects. The only thing I can think of for which any granting would occur for MOVOBJ is if the object spanned an ASP and thus the implementation of /move/ was via a save\restore.?

FWiW: If I dump all the internal objects in a library into which I had just created the supposed *AUTHLR object [Create Authority Holder (CRTAUTHLR); program QSYCRHLR] or from which I deleted the supposed *AUTHLR object [Delete Authority Holder (DLTAUTHLR); program QSYDLHLR], I see no indication of the object type in the dump, nor did I notice anything in a dump of the user profile to obtain a list of /authorized/ objects -- much like Display User Profile (DSPUSRPRF) for *OBJAUT and *OBJOWN type of information combined, but expected to have no limitations on object types presented. So while I allude to them being an actual /object/, there seems to be little support for that perspective; instead they may exist only as index entries in the /LIC-Context-object/ that represents the Library (*LIB) object.

If the Dump List (DMPLST) of MCH3602 were modified to include the *JOB [for which a QPDSPJOB is produced for the DSPJOB effect implied with that special-value *JOB] that would include the program stack in any recurrence of the failure after that change to the message description, then the caller of the QSYGRHLR would be revealed; that ought to be interesting.

If\When the issue gets address eventually as a PMR, presumably will be so, please suggest they add to the message MCH3602 a Message Data Fields Formats (FMT) for the *HEX representation of the pointer if that being included by the signaler of the exception x2402 could be somewhat revealing; e.g. the message MCH3603 has FMT((*HEX 16 0)) defined -- the same I'd long wished they'd have done for message MCH3402, because if nothing else, the object-type\subtype would be visible for that error, when the pointer to the since-destroyed object was a System Pointer (*SYP) to an external object.