× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Thanks.

On Fri, Dec 4, 2009 at 9:03 AM, Luis Rodriguez <luisro58@xxxxxxxxx> wrote:

Jack,

Just wondering... If you suspect that your size problems reside with a QSYS
file, maybe you could do a DSPFD to an outfile, and use that data instead
(at least ib our system it seems to be a bit faster). Try this:

DSPFD FILE(*ALLUSR/*ALL)
TYPE(*MBR)
OUTPUT(*OUTFILE)
FILEATR(*ALL)
OUTFILE(MYLIB/FILELIST)

You could run a QRY/SQL against MYFILE/FILELIST and check your biggest
files, even checking if they have a lot of deleted records. In fact, you
could even narrow your field using FILEATR(*PF). I found here that someone
had defined a transaction file as REUSEDLT(*NO). Very soon it had about
1,700,000 records deleted, and only some 500 "valid" records.

HTH,
Luis Rodriguez
IBM Certified Systems Expert — eServer i5 iSeries


On Fri, Dec 4, 2009 at 9:10 AM, Jack Kingsley <iseriesflorida@xxxxxxxxx
wrote:

Thanks for the reply.

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

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
to
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
a
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
to
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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.