× 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.



Al:

Your questions: There were shared folders (moderate, I'd say), but not IFS,
on
the system I was testing. And, yes there were source files, but no (or
almost
no) data files with multiple members. So, maybe the source files with all
their
members have some impact. It's worth considering, and something I hadn't
really
thought about.

Oh, you're definitely right that there are differences, and there are plenty
of
times when I would use DISKTASKS instead of DSPOBJD. However, if the system
is
large with lots of objects, I just found I couldn't wait for DISKTASKS.

Here are some of the similarities and differences I found in using DSPOBJD
and
DISKTASKS:

For DSPOBJD, there are no shared folders, so you also need to run the
QRYDOCLIB
to get the shared folder info.

Both files have the Last Used Date and Last Change Date for each object.
These
dates are very useful for determining what may be old and useless on your
system.

The DISKTASKS file has the object size for each object, including documents
in
shared folders. It even shows a size for the Licensed Internal Code, which
is
not reported as an object. (Note - I don't care much about the space
required
for LIC, because I can't do anything about it.)

With the DSPOBJD method, the object size must be calculated by multiplying
fields ODBPUN and ODSIZU.

The DSPOBJD outfile has the name of the system for which the information was
obtained, while the DISKTASKS file doesn't. If you run reports for multiple
systems, you really need to print the system name on your reports.

The DSPOBJD outfile also has the user profile of the user who created each
object as well as the object owner, but the DISKTASKS file has only the
object
owner and does not indicate the creator. The creator of an object is very
helpful to know if you have to find out what the object is for and if it is
needed on your system anymore.

So, here's the conclusion I came to:

If you run a small shop with a single system that doesn't have a lot of
variability, you will probably find that DISKTASKS suits you just fine. You
can
put it on the scheduler and check the reports once or twice a month.

However, if you have several large systems, a lot of fluctuations in storage
used, and many staff members who may have created objects, you will probably
find the few extra steps required to make use of DSPOBJD worth your while.

If your shop is something in between, you could try running both methods for
a
month or so, and see what suits your situation best.

Most of the above is copied from the aforementioned article I wrote for the
TUG
magazine in 98. As I mentioned before, there may be system changes that
would
cause me to change my conclusions. Basically, every shop needs to choose
whichever method works best for their particular circumstance.

Regards,
Debbie Gallagher




********************
Original message
********************
Date: Tue, 07 Sep 1999 13:29:09 -0700
From: "Al Barsa, Jr." <barsa2@ibm.net>
Subject: Re: DASD Usage - DISKTASKS

At 01:30 PM 09/06/1999 -0400, you wrote:

In fairness to OA, Disk Collection does a lot more than DSPOBJD, but I 
cannot readily explain the differences.

A few questions:

Does this system have many:

multi-membered files (source files count)
DLO objects
IFS objects?????

Al


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.