RE: RTVDSKINF Data Question -- MIDRANGE-L

No worries.

But rather than wait a couple of hours for RTVDSKINF to complete, you
could quite quickly use DSPUSRPRF as suggested. Depending on how your
system is setup, this may have given you enough information to determine
where space was being consumed. If you are approaching your threshold
limit, RTVDSKINF may even push you over the threshold if you are taking
copies of QUSRSYS/QAEZDISK.

...I them rambled on about how this method could be used as an ongoing
tool...

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jack Kingsley
Sent: 04 December 2009 13:15
To: Midrange Systems Technical Discussion
Subject: Re: RTVDSKINF Data Question

Sean, this all sounds great, but the problem I had would not allow me to
install any new solutions to come up with a possible answer to the
problem.
The problem was one which requires an immediate solution if one so
exists,
at the time the only way I could come up with resolving it was to use
the
RTVDSKINF/PRTDSKINF combination since I know that this data was present
on
the box.

On Fri, Dec 4, 2009 at 4:21 AM, McGovern, Sean
<Sean.McGovern@xxxxxxxxxxxx>wrote:

Others have commented on how to go about this, but also consider that
DSPUSRPRF *ALL to an OUTFILE runs relatively quickly (quicker than
RTVDSKINF anyhow) and shows how much space is being consumed by each
user profile. Performing DSPUSRPRF on a regular basis and storing the
results in separate tables, allows quick comparisons to be made. This
may give a good clue as to where space is being consumed.

It helps if you can split the objects on your system, the ones that

are

likely to vary in size, to be owned by numerous user profiles. As a
simple example, change the owner of your order entry database tables

be ORDPRF, change the owner of your inventory database tables to be
INVPRF etc. Changing the owner of database tables has no impact on
security.

By making good use of having numerous owning user profiles, you can
quickly determine which user profile is increasing/decreasing
significantly. You can then use QSYLOBJA to list all objects owned by

user, and QUSROBJD to retrieve the size of each of those objects. By
narrowing the search in this way, you can quickly determine where
significant ASP increases/decreases are occurring.

I've written a tool that uses the above method to monitor ASP changes.
Our box is currently 1690G in size of which 50% is used. The
monitor/alert tool monitors everything on the box and finds

significant

increases/decreases usually within 5 minutes, much quicker than

relying

on RTVDSKINF. The key is having numerous owning user profiles.

BTW, I wasn't impressed when I read the Robot/SPACE manual. It seemed
that it didn't monitor everything on the box, you had to setup which
objects to monitor.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jack Kingsley
Sent: 03 December 2009 18:27
To: Midrange Systems Technical Discussion
Subject: RTVDSKINF Data Question

Is there a way to create seperate instances of the RTVDSKINF data. It
looks
like saving it then restoring it back would be the only way. I need

find
out what is consuming disk storage on a machine and I wanted one to

use

as a
benchmark per-se.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)

mailing

list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.