Re: CPY command works on one system, but not another...

[Kirk Goins <kirkgoins@xxxxxxxxx>]

Tom,
CRPense gave me the following tip when I was trying to find error. The key
part was to review the QAUDJRN for Authority Failures ( T-AF codes ) in the
journal. If yo are not currently using the audit journal you can set it up
pretty easy.

CRTJRNRCV JRNRCV(YOURLIB/QAUDR0001)
CRTJRN JRN(QSYS/QAUDJRN) JRNRCV(YOURLIB/QAUDR0001)
WRKSYSVAL QAUD* and change
QAUDCTl to *AUDLVL
QAUDLVL to include at least *AUTFAIL

Now try you cmd and then use the DSPJRN cmd to serach fot the T codes with
AF





 When server jobs fail to properly start, and a joblog does not
conspicuously reveal the cause, I almost always look for T-AF entries in
the auditing as a likely origin... which I have many times found to be
the cause, and thus /correcting/ the authority for the object(s) to
which the user is not authorized would resolve the problem.


On Tue, May 28, 2013 at 1:49 PM, Tom Hightower <tomh@xxxxxxxxxxx> wrote:

> I have a client with two v6r1 System i boxes. On each system, the client
> is running software which has created IFS objects in folder /images.
>
> On each, I'm running this command:
>
> CPY OBJ('/IMAGES/010108/0001/AAAAGBOU.*') TODIR('/home/idocket')
>
> On System1, it works without problem.  On System2, I get the following
> error:
>
> CPFA0A2 - Information passed to this operation was not valid.
>
>
> Digging into a bit and using DSPAUT on each system, I see the following:
>
>                               Display Authority  (System1)
>
> Object . . . . . . . . . . . . :   /images
> Type . . . . . . . . . . . . . :   DIR
> Owner  . . . . . . . . . . . . :   QSECOFR
> Primary group  . . . . . . . . :   *NOUSRPRF
> Authorization list . . . . . . :   *NONE
>
>               Data     --Object Authorities--
> User        Authority  Exist  Mgt  Alter  Ref
> QSECOFR     *RWX         X     X     X     X
> *NOUSRPRF   *RWX         X     X     X     X
> *PUBLIC     *RWX         X     X     X     X
>
>
>
>                                    Display Authority  (System2)
>
>  Object . . . . . . . . . . . . :   /images
>  Type . . . . . . . . . . . . . :   DIR
>  Owner  . . . . . . . . . . . . :   *NOUSRPRF
>  Primary group  . . . . . . . . :   *NOUSRPRF
>  Authorization list . . . . . . :   *NONE
>
>                Data     --Object Authorities--
>  User        Authority  Exist  Mgt  Alter  Ref
>  *NOUSRPRF   *RWX         X     X     X     X
>  *NOUSRPRF   *RWX         X     X     X     X
>  *PUBLIC     *RWX         X     X     X     X
>
>
> The only difference that I see (so far) is that the Owner for the
> '/images' directory is QSECOFR on System1, but on System2 it is shown as
> *NOUSRPRF.
>
> I've contacted tech support at the software vendor about it, asking if
> that might be the problem.  Their response: "Don't know. Good luck."
>
> So... could the owner being set at *NOUSRPRF be what is preventing me from
> performing the "CPY" command? If so, how do I get around it, other than
> changing object owner?
>
> TomH
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.