ell, what do you know about your biggest objects? Do you know exactly which are the largest objects? Should they be the largest? Do you know how much they've grown? These are good questions to ask, and if you are responsible for disk storage, you should find out the answer to each question.
Start by creating a file that has information about every object on the system. If you don't already have a file with object information, read my article from January 1996, "Where Did All The DASD Go?". (If you missed it, check out the TUG web site at www.tug.on.ca , and surf to the magazine Archives.)
If you have used DISKTASKS to collect storage information, the object size is in field DIOBSZ. You can use Query/400 to exclude all DISKTASKS records where the library name is blank, as these records do not represent objects.
If you have used DSPOBJD to get the object information, you need to calculate the correct object size. The outfile from DSPOBJD does have a field ODOBSZ, which used to be always the object size, but it is defined as a 10.0 field, so it does not correctly report objects that are 10 gigabytes or more. You can create a result field in Query/400 for the correct object size. To calculate object size, multiply field ODBPUN (bytes per unit) times field ODSIZU (size of unit).
Use the Select Records feature of Query/400 to print a report on the largest objects on your system.
You'll need to define what you consider a large object. If you have twenty gigabytes of DASD, the object size you report will be very different from someone who has two hundred gigabytes of DASD. To choose an object size for reporting, try different sizes until you get a report that is one double-spaced page or less.
Now that you have a report of the largest objects on your system, review it carefully. Do you know what the purpose of each one is? Are there any surprizes? Probably most of the large objects are physical files, but you may find a journal receiver or save file or even a logical file on your report.
Ask and find out whether each object really should be one of the largest on your system. For example, are any of the objects history files, or year-to-date files? If so, should they really be so large, or has the program to remove the obsolete records not been run (or written)?
Check the last used dates on your large objects. Maybe some of them are not actually used. For example, did someone create a copy of your biggest file before implementing a program change? Is it still there a month (or year) later? Have you got journal receivers that have never been detached and deleted?
Run and review this Large Object report regularly. Watch for unexpected changes in size, or objects appearing on the report for the first time. If you watch the report regularly, you will be able to recognize unusual changes. Then you can take action to reduce object size, or buy more disk if the extra storage is really needed.
It is also a good idea to think about whether the object sizes reported make sense to you. Occasionally, there are problems with reporting of object size that require correction by application of a PTF. If the object size reported looks strange, have a closer look.
One time I noticed that several files on my report were exactly the same size, even though the record length and number of records were different for every file. The similarity in size (all were 2.147 gigabytes) seemed highly unlikely. A PTF was needed to correct the problem.
Several months ago, another report showed a file with a size of 9,999,999,999 bytes. Numbers that are all nines always get my attention, and in this case it was the field ODOBSZ which had reached its reporting limit. I had not been aware until then that I should be reporting object size based on multiplying the fields ODBPUN and ODSIZU.
My most recent occurrence with strange numbers was the reporting of a file as more than a terrabyte in size. This number was obviously completely wrong, and also required the application of a PTF.
Generally, I have found that when object size is incorrectly reported, it is when the object is huge, not when it is small. Keeping an eye on the largest objects helps to identify disk usage reporting problems. This identification is necessary when planning disk purchases.
Once you have the answer to each of these questions, keep asking them again periodically to see if the answers have changed.