Q: I use the Save Security Data (SAVSECDTA) command to back up security information on a weekly basis. However, when I use Display Object Description (DSPOBJD) for a user profile, the save information does not show the date and time of the backup. How can I see when I last saved user profiles?

A: Before I answer your question, you should be complimented for remembering to save the authorities on a weekly basis. Many installations have scheduled backup procedures for their data files but fail to save user profiles regularly. If the last save of the user profiles took place when you last executed a Save System (SAVSYS) command, it may be impossible to recover all the intervening changes to user profiles, authorization lists and the authority to objects. A weekly save of user profiles is important. User profiles can be saved by either a Save System (SAVSYS) or a Save Security Data (SAVSECDTA) command. The advantage of SAVSECDTA is that it does not require a dedicated system and can be done while users are signed on to the AS/400.

Now, for the answer to your question. IBM does not record the save and restore information in each user profile object. This improves the performance of the save operation since the information would be the same for all user profiles. IBM uses the QSAVUSRPRF data area in library QSYS to record the date and time for the SAVSECDTA command. To view the last time user profiles were saved, run Display Object Description (DSPOBJD)-and not the Display Data Area (DSPDTAARA) command-for data area QSAVUSRPRF. Specify *FULL for the DETAIL parameter to show the date and time of the last save operation.

Q: We want a group of users to share the documents created by other users. The users who should be able to share the documents are members of the same group profile and transfer the ownership of new objects to the group profile.

I encounter problems when PC users create new PC files which are stored as documents in an AS/400 folder. The PC files cannot be accessed by anyone else. The group profile owns the folder and public authority is *EXCLUDE. If we change the public authority to *ALL, the user can see the documents. However, if these documents are accessed through a PC package such as Lotus, a network security error is presented.

A: Document library objects (DLO) do not transfer ownership to the group profile like the other objects on the system. The creator of the document or folder (PC file or directory) will be the owner of the object even when the user profile says OWNER(*GRPPRF). New documents inherit their authority from the folder in which they are placed. Since the public authority to the folder is *EXCLUDE, the new documents (PC files) will also have *EXCLUDE and users other than the creator (even if they are members of the same group) will not have the required authorization to read the documents.

If you secure the folder by an authorization list, new documents added to the folder will also be secured by the same authorization list. If the group profile is on the authorization list, members of the group can access the documents, eliminating the network security problems. Only new documents will be secured by the authorization list. If documents already exist in the folder, you can use the Change DLO Authority (CHGDLOAUT) command to secure the existing documents by the same authorization list. This command supports *ALL for the name so all documents can be secured in one operation.