× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.






As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.