Re: Need to shrink my profile

It gets worse and worse. <sigh> So the moral of this particular story is to not let your user profile get too big. Good thing this isn't QSECOFR or some other required user profile.

Joe

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.