Re: Weird authority issue, supposedly on object in QTEMP

On 29 Jun 2012 10:39, James Lampert wrote:

We have a customer who has some extremely weird things going on with
one user. Here is an excerpt from the joblog:

MCH1001 F/#auexcpt x/000C18 T/QDBCRTFI Tm/QDBCRTFI Tp/CREATE_FCB_OBJECT stmt/38348 "Attempt to use permanent system object <user-ID>"
CPF3223 f/QDBCRTFI Fm/QDBCRTFI Fp/SEND_PMSG stmt/38945 T/WTGOSQLR Tm/WTGOSQLR

Tp/WTGOSQLR stmt/1068 "Not authorized to objects needed for file WTGRPSQ in QTEMP."

CPF2883 F/QCPCREAT x/0086 "Error creating file WTGRPSQ in library QTEMP."
CPF2817 F/QCPCREAT x/0086 "An error occurred while the file was being copied."
CPF9999 QMHUNMSG "CPF2817 unmonitored by WTGOSQLR at statement 0000001068"
R?????? F/QRNXIE Fm/QRNXMSG Fm/InqMsg Stmt/15 "RPG procedure WTGOSQLR in program WINTOUCH/WTGOSQLR at statement 1068 called program or procedure *LIBL/QCMDEXC, which ended in error."

The statement 1068 referred to is a simple QCMDEXC call, doing a CPYF
of the file WTGRPSQ (which has *PUBLIC *ALL authority) into QTEMP.

Is it even possible for a user to NOT have authority to his or her
own job's QTEMP?

The issue appears to be due to missing authority to the unnamed user profile object; presumably missing authority to itself, or to a group profile of the user. Less likely, perhaps instead to some object named the same as that user profile object; re-representing the message data as 16-byte character in HEX would show the object type\subtype, or the T-AF entry from the auditing would similarly clarify the actual object to which the current-user\job\invocation-level was not authorized.

What are the OWNER, GRPAUT, GRPAUTTYP for the user, and are the user's authority to any group different than when a user is first assigned to a group?

IIRC, a common issue for authority gone missing to a group profile is a side effect of some prior CHGOBJOWN activity. I can not think of a specific scenario, though I recall encountering it myself, but I think specifically as an effect from using CUROWNAUT(*REVOKE).

FWiW: While likely difficult to effect [e.g. GRTOBJAUT not allowed to effect], because a QTEMP library is a permanent object for which object authorities are tracked, indeed a user _could_ lack authority to that type of /LIC context/ object. Additionally, a user could even create objects into a QTEMP library, to which they are not authorized, neither for change nor even delete; most easily effected by assigning group ownership or using adopted authority.

Regards, Chuck