Storing system documentation on the iSeries

I'm trying to store system documentation on my system, specifically MS Word documents on a shared drive in the IFS. This works fine, but Word always creates a hidden backup of each document which for some reason it cannot delete from the IFS. I have to exit Word, alter the backup to remove the 'Hidden' attribute and then delete it. Why can't Word tidy up after itself on IFS. I'm thinking that the directory is secured by an authorization list specifying *PUBLIC *CHANGE so authority shouldn't be a problem. Is that correct, or is there any way from the iSeries end of spotting (and removing) files with the DOS/Windows 'Hidden' attribute?
What I believe is happening is that the authority to the IFS directory you are creating your documents in is insufficient.

When a user creates a new file in an IFS directory they become the owner of the file and therefore have all DATA rights, but the OBJECT authority assigned to the file is based on the authority of the directory it is placed in. Here are the rules:

1. The owner for the new object has the same object authorities that the owner of the parent directory has to the parent directory.

2. The primary group for the new object has the same object authorities that the primary group of the parent directory has to the parent directory.

3. *PUBLIC has the same object authorities to the new object that it has to the parent directory.

In your word processing example, the word processing program creates a temporary file when a file is created or opened for edit. When the user finally saves the document and exits, the PC program attempts to rename the most current temporary file to the original file name. If the user's objects didn't get sufficient private authority from the parent directory (which I suspect they aren't) then this operation can't be completed.

So, check to see who the OWNER of the parent directory is and what authority they have to it because this will be the authority assigned to any new object created in that directory.

If the OWNER of the directory is different than the user creating the object in the directory (which is probably the case) then the *PUBLIC authority setting comes into play.

The simplest fix to your problem may be to assign *PUBLIC authority like this: 

                                            
               Data     --Object Authorities-- 
 User        Authority  Exist  Mgt  Alter  Ref 
                                               
 *PUBLIC     *RX                X

Here is IBM's explanation of "mgt object authority":

The object authorities that the user has to the object. An "X" in the column indicates that the user has the specified object authority to the object named. The specific object authorities are:

Mgt Object management authority provides authority to specify security, to move or rename the object, and to add members if the object is a database file. Good Luck! Let me know if this solved your issue.

This was first published in September 2005

Back to top