RE: Large Objects created on AS400 consuming huge disk space

["Dennis Lovelady" <iseries@xxxxxxxxxxxx>]

>    Of course the idea that there are any "large objects" to be
> located is inherently flawed.  Unless the objects responsible for
> the growth are already known, there is no way to know if the
> increase in storage was by many small objects or even possibly by
> small increments to existing objects of any size.
>
>    If the storage increase is to "permanent storage" versus
> "temporary storage", the quickest method to track percentage
> differences is by user profile; even without knowing which old or
> new objects might have grown, this possibly enables determination of
> which user(s) to "chase".  A [baseline] snapshot of the current
> storage taken by each *USRPRF can be obtained using DSPUSRPRF
> TYPE(*BASIC) OUTPUT(*OUTFILE), and then later [e.g. after a change
> in permanent storage space is noted], obtain another Display User
> Profile output file that is then used compare the difference in the
> UPMXSU "max storage used" field from the baseline snapshot to the
> current snapshot.

Of course, this method is likewise inherently flawed in that it assumes some
individual user's objects are at the heart of the growth. There is no
one-size-fits-all solution; there is no best way; there is no "quickest
method" to determine the root of the problem.  While one may work for you
this time, it may fall short next time.  

For example, in more than one client implementation I've worked, all objects
that are promoted (by Turnover) end up being owned by a single user on the
Production system.  When storage utilization starts growing, it's a safe bet
that that's the user who will be charged with the growth.  But in fact there
is no one to chase.  No matter what user is actually adding to the data, the
owner of the file - completely innocent in this case - is the culprit by
this analysis.

The comparison against baseline that's given (by User Profile) may work for
you this time.  For another time, a comparison against baseline using
DSPOBJD may do the trick.  An analysis of IFS directory growth may reveal a
problem sometimes and for others RTVDSKINF may be the savior.  In fact, all
of these tools have value in the administrator's toolbox, and none of them
is better, except of course the one that solves the current problem.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"I would rather men should ask why no statue has been erected in my honor,
than why one has."
        -- Marcus Cato (2nd century BC)
"It is better to deserve honors and not have them than to have them and not
deserve them."
        -- Mark Twain