On 25 Apr 2013 14:24, Joe Pluta wrote:
So the moral of this particular story is to not let your user
profile get too big.
Pretty much. I am not aware of nor do I think there is an event to
notify of a specified percent full being reached. The PRTPTFINT
reporting can be periodically reviewed in lieu of a notification. Not
as easy as reviewing the Max Storage (MAXSTG) setting vs Storage Used
:-( per lack of a described model output file for that Print Profile
Internals request, as there is with DSPUSRPRF for TYPE(*BASIC)
information which offers the model file QADSPUPB format QSYDSUPB and
fields: UPMXSU and UPMXST.
Maybe worth submitting a Design Change Request to ask for a Max
Percent Full setting for the user profile and a Percentage Full
attribute returned in DSPUSRPRF TYPE(*BASIC) OUTPUT(*OUTFILE).? I
suppose the information was externalized as it was [i.e. PRTPRFINT] for
some reasons... and those reasons may be in conflict with a change
request to supply that information via DSPUSRPRF, but there seems little
harm in asking.
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/cl/prtprfint.htm
_i Print Profile Internals (PRTPRFINT) i_
...
Recommendations to avoid profiles becoming full:
* Do not have one profile own everything on your system. For
example, have each application be owned by its own profile.
* Do not use IBM-supplied profiles, such as QSECOFR and QPGMR, as
owners of your application. As shipped from IBM, they already own many
objects and can become full when they also own user (non-IBM) objects.
* If you are granting private authorities to many objects for
several users, you should consider using an authorization list to secure
the objects. Authorization lists will cause one private authority entry
for the authorization list in the user's profile rather than one private
authority entry for each object. In the object owner's profile,
authorization lists will cause an authorized object entry for every user
granted authority to the authorization list rather than an authorized
object entry for every object multiplied by the number of users granted
the private authority.
Authorization lists are especially useful if you are granting
private authorities to files. Files are complex objects. For complex
objects, you get an entry for each piece of the object. For example, in
a file owner's profile, you have an ownership entry for each piece of
the file, including an entry or two for each member. (Physical files
have two entries per member.) If you grant a private authority to ten
users and the file has 50 members, the result will be 100 authorized
object entries in the file owner's profile. With an authorization list,
the ownership entries will remain the same, but the authorized object
entries will be reduced to one for each user granted authority to the
authorization list securing the file.
..."
For stream files and [sub]directories, I would have expected the
feature to /inherit/ authority from the directory in combination with an
authorization list assigned as authority to the directory could be
helpful for limiting the growth in the size of the profile [due to
authorities] similar to how using a Authorization List can assist for
database files. However, on v5r3 anyhow, the ability to set the
/object/ rights seems not possible to be set to the *AUTL as can be done
for the /data/ rights.?
Good thing this isn't QSECOFR or some other required user profile.
As the above doc snippet warns.
I have helped resolve some situations with system user profiles
having reached the limits. Basically starting with a program to either
CHGOWN RVKOLDAUT(*YES) and CHGOBJOWN CUROWNAUT(*REVOKE) of most objects
to assign to a couple other profiles, or RVKOBJAUT *ALL for authorized
objects when unnecessary authorities were granted [e.g. to recover from
stupid requests like effectively GRTOBJAUT *ALL/*ALL *ALL USER(QSECOFR)
AUT(*ALL)] which oddly, I had to do way too many times in the lab :-( to
cleanup after some #$(*&^@ !#^$%^ who did not have the sense to realize
the request was moot. If the user profile had already exceeded its
limit, then the recovery had to start with /simple object types/ first,
to avoid the attempt to recover from failing due to an inability to
create permanent internal objects which would implement the request for
complex object types like database files; permanent objects must be
assigned an ownership authority and by default gets a private authority
of *ALL. Then when all was to where it should be, other than the size,
get the final list of remaining objects, get a SAVSYS [and SAVSECDTA],
hard damage the user profile object, delete the user profile [which
could require a patch or some tooling], then either RSTUSRPRF of the
deleted *USRPRF object or perform what IIRC was called an /abbreviated/
slip install to get the OS to re-create the missing user profile, and
then run a program [using the list generated previously] to assign
ownership of the objects to the new user profile with the same name [in
some cases, due to defects, I believe a RCLSTG *ALL was required first,
to set the owner to QDFTOWN; i.e. some interfaces improperly might have
been unable to handle the current owner being unassigned or owned by a
destroyed object] ¿and then revoke all authorities to the object for
that user? [that ¿step?, if RstAut is merely additive; I can not
recall], and finally issue the RSTAUT.
midrange.com
