RE: IFS File CHGAUT Oddity

That is true but I have found it has the same restrictions for the Unix part of 
the IFS.  My work around has been to have the job creating the object do a 
CHGAUT for *PUBLIC to add or remove authority as needed.  This gets makes sure 
the object is correctly for the IFS and gets past the error if another user 
(not the owner or *ALLOBJ) tries to alter *PUBLIC authority..  

Otherwise for the QSYS.LIB file system RVKOBJAUT or GRTOBJAUT might be a better 
choices.

$.02 worth

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of richard@xxxxxxxxxxx
Sent: Friday, January 05, 2007 11:34 AM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: IFS File CHGAUT Oddity


Actually the link reads:

Restrictions: If changing authority for an object in the QSYS.LIB file 
system: 

1.      A user must either be the owner of the object or have *ALLOBJ 
special authority to use this command on an object. 

According to the docs this should only occur if the object is in QSYS.LIB 
:-)

Regards,
Richard Schoen
RJS Software Systems Inc. 
"Providing Your....iNFORMATION NOW!"
Email: richard@xxxxxxxxxxxxxxx
Web Site: http://www.rjssoftware.com
Tel: (952) 898-3038
Fax: (952) 898-1781
Toll Free: (888) RJSSOFT
-------------------------------
message: 3
date: Fri, 5 Jan 2007 07:43:16 -0800
from: "Holder, Ken" <kkh@xxxxxxxxxxxxx>
subject: RE: IFS File CHGAUT Oddity

-------------------------------------------------------

It's working as designed.  I've been down this road too.

http://publib.boulder.ibm.com/iseries/v5r1/ic2924/index.htm?info/cl/chgaut.htm


Restrictions: 

1.  A user must either be the owner of the object or have *ALLOBJ special 
authority to use this command on an object.