go disktask, run a disk scan, then a disk analyze : you have many data on objects ans libraries. Make cross references with sql.
regular rgzpfm to reclaim deleted recors space
regular IPL to reclaim QRCL space. Daily on a dev machine, weekly or less on a production-only machine
There should rarely be a need to RGZPFM any files at all if files are generally properly defined and used. Nor is it likely to recover much of the capacity of the system. Also, IPLs probably don’t need doing more than once a month or even a quarter, though they can bring back some temporarily used space… temporarily. Because it’s temporary space, it should <b>not</b> be relied upon for capacity.
First, learn and understand how your environment uses its space.
<li>Are database files large? Are there many database files?</li><li>Are streamfiles in directories prevalent?</li><li>Is journaling important?</li><li>Is auditing or job accounting active?</li><li>Are many spooled files created and retained unnecessarily?</li>
One key to space management is knowing how space in needed on your system. If your applications tend to create many small streamfiles, e.g., faxes received and retained in a structure of subdirectories, you might be wasting your time trying to improve space utilization within your database applications. Percentage-wise, your database files probably don’t matter much in that environment.
Web serving? Java apps? Windows network shares for storage?
Is your business database-intensive? Large numbers of transactions being processed and recorded, commitment control, database journals…
If those activities take up more than half of your system, outside of system libraries, then that will be your first priority. Begin with journal receivers.
Do WRKOBJ *ALL/*ALL *JRN to learn of all journals on your system. There will be at least two general kinds — some will be in libraries that are obviously system libraries, QSYS, QRECOVERY, QMGT, etc.; and others will be in application libraries. Take some time to learn if system receivers are being automatically deleted. Use WRKJRNA against each journal to learn how long the lists of attached receivers are.
The big journals (if they exist) may be QAUDJRN and, less likely, QACGJRN. Ensure that their receivers are in libraries being saved regularly and that the receivers are being deleted automatically. Other system journals can be reviewed later as time permits. For most, if excessive receivers exist, delete older ones.
After system libraries, work your may through your application journals. Journal receivers can pile up quickly if no one pays attention.
QRPLOBJ is worth reviewing, though it shouldn’t be a significant factor. Look over the pattern of objects to see if user spaces, for example, are being recreated at a high rate and getting moved to QRPLOBJ. An IPL clears the library, but a minor change or two to applications might reduce the need.
Programs in QRPLOBJ usually aren’t worth worrying about. Add up the sizes to compare against disk capacity to get a feeling for them. PDM gives an easy way to delete all objects of a given type. Don’t use CLRLIB without knowing all the objects because the system itself can use the library too.
Maybe the best way to learn your system space needs is weekly RTVDSKINF and RTVDIRINF. You can then run PRTDSKINF and PRTDIRINF to see where space is used. You can also query the files from those commands yourself. Weekly runs will show you changes to guide you in deciding where to put your cleanup efforts.