Re: Large Objects created on AS400 consuming huge disk space

I wrote a utility called disk/HUNTER while at a former employer - it is now available as DASD-Plus Alert and info is at http://www.s4isystems.com/products/dasdplusalert.asp

I won't say how it works - and I don't work for s4i nor for the company where I wrote it. My boss had the idea and gave me the task to write the thing. It runs all the time as a monitor and is very lightweight as to system impact, then when excessive growth occurs it goes out looking for where the trouble is. It is real-time, checking at a configurable interval, so it finds problems that RTVDSKINF can't until far too late. And it can find problems long before 95% space used knocks you down.

I would suggest this product to the original poster - it fits his question, as I recall.

Vern

Dennis Lovelady wrote:

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