Re: Need to shrink my profile

On 25 Apr 2013 11:48, Joe Pluta wrote:

No, this isn't spam. :)

Seriously, my user profile has grown to the point where it is
affecting our system saves. I looked and my *USRPRF object is nearly
a gigabyte in size. I tracked it down to it more than likely being
caused by the fact that I've created literally millions of IFS files.
(Don't ask why; I'm trying not to cast aspersions.) It's not
important anyway since I'm trying to get rid of the files. I'm
ZIPping the files together and deleting them, but I don't see any
effect yet on my user profile.

When do you think my user profile will slim down? Later today? After
an IPL? Never?

AFaIK the index object which implements the user profile [*USRPRF object type] can only grow. That is, much like the index object that is the LIC Context [i.e the index that implements the *LIB library object] can only grow.

While there is possibly a /method/ which enables truncating such an index object, I am not aware of any such method for either object type that is exposed to any external interface to reduce the size; not even any RCLxxx interface for the object types, although a user profile can have its authority tables compressed during a RCLSTG *ALL request [which includes an /authority recovery/ phase]. Nor am I aware of any feature which utilizes the /destroy index/ instruction as a means to effect anything similar, while maintaining the original external object type *USRPRF [or similarly *LIB]. The only way I know for sure to fully reduce the size of the internal index which implements those external object types, is to use the DLTUSRPRF [or DLTLIB] which will effect the actual /destroy index/ action to delete the implementation object of the external object type; after which a new index can be populated from empty. That of course requires whatever planning to allow that action can occur, without losing whatever else that should be maintained.

For a library the algorithm is basically one of either: SAVLIB the_lib, DLTLIB the_lib, CRTLIB the_lib, RSTLIB the_lib or RSTOBJ *ALL the_lib, and then set ownership and authority to the new\replacement *LIB object. RNMOBJ the_lib *LIB old_lib, CRTLIB the_lib, MOVOBJ of all objects from old_lib to the_lib, CHGOBJOWN the_lib, GRTOBJAUT the_lib *LIB REFOBJ(old_lib), DLTLIB old_lib

For a user profile the algorithm is similar, but the save\restore of objects is potentially very complicated, because the objects to save and restore are not limited to just a single library. Thus acting without media is easiest, though without a RNMOBJ capability for a user profile, the process is a bit annoying for the duplicated work. There are also issues such as directory entries which must be dealt with separately, plus any "Additional Considerations" noted in the docs; especially with regard to *LIB and *DIR objects for which ownership will be transferred to QDFTOWN, which is best proactively dealt with, or instead recovered-from for which ensuring QDFTOWN owns nothing before starting is ideal:
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/cl/dltusrprf.htm

Such an algorithm for a user profile is: CRTUSRPRF new_usr, GRTOBJAUT new_usr REFOBJ(the_usr), DLTUSRPRF the_usr OWNOBJOPT(*CHGOWN new_usr) PGPOPT(*CHGPGP new_usr), CRTUSRPRF the_usr, DLTUSRPRF new_usr OWNOBJOPT(*CHGOWN the_usr) PGPOPT(*CHGPGP the_usr)

That said, the implementation of the actions combining a SAVSECDTA with both a RSTUSRPRF and a RSTAUT for a specific user profile object *may* enable fairly full compression of the user profile authority tables. That is because the RSTUSRPRF in effect just restores a list of all object names to which private authorities will be restored. As I understand, the Restore Authority request would then rebuild the current tables of authorities [private, primary group, and supplemental group], presumably as maximally compressed, but the ownership table would remain unchanged. The effect on the index... I do not know, but as noted, I believe RCLSTG *ALL might perform some compression. FWiW, the Reclaim Objects by Owner (RCLOBJOWN) likely does not include that same work, but one could test.