Answer Wiki

Thanks. We'll let you know when a new response is added.

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.


Discuss This Question: 3  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Dlevine
    As is said in the previous reply, you should have some sort of scedule for reclaiming storage, and reorganizing your physical file members. Something else (and I know that we go through this all the time) - be aware of excessive amounts of spool file output. Get rid of anything you dont need... we have an OUTQ where we can move spool files, and have written a CL program to clear it out once a week. You can also archive spool files off the system with various free and commercial tools (we use Winspool by RJS Software). Also keep an eye on any journal files you may have. As the receivers fill up and are disconnected, make sure that you are clearing the old ones off (if possible). HTH
    0 pointsBadges:
  • TheQuigs
    Yes, watch out for journal receivers. If you're creating your database with SQL DDL (Data Definition Language), the default is to journal everything. I heard about some systems where it was discoverred that they had 80-90% of their disk used to store old journal receivers. They had no idea they were journalling the files. There are some good articles on journal receiver management. If this appears to be your problem, go to your favorite search engine and type in something like "OS/400 Journal Receiver Management". You should get some good hits. If you need more information, I can supply you with a few links.
    0 pointsBadges:
  • JohnDavid
    Hi, I think I might have responded to message already but here goes: 1. Performance data - Have a look at the libraries QMPGDATA and QPFRDATA and delete old data. You usually need performance data for a short period such as planning for an upgrade or solving some or other kind of performance problem. After that the data becomes stale. 2. Journal receivers - Have a look at all your journal receivers. Cycle the journals, save and delete old receivers. Do this on a regular basis. Pay attention to the receivers of QAUDJRN. Also pay attention to the SQL receivers attached to the QSQJRN journals. 3. Clear the following libraries - QRPLOBJ, QSRV and QRCL. Please attend to all issues in QRCL first. 4. Identify and delete (where possible) all save files and command output file. This can be done through the DSPOBJD *ALL/*ALL *FILE command to an output file. Run a query over the output file. Save files have an attribute of SAVF and the descriptions of command output files start with 'Output file for '. 5. Check and delete all libraries starting with the character QSC... These libraries are created when errors are detected. I use WRKPRB and WRKALR to manage problems. Also our system is not connected to IBM through ECS. 6. Identify objects, files and programs, that have not been used for some time. This can be done though the DSPOBJD *ALL/*ALL *ALL command to an output file. Run a query over the file and check the data last used. Archive and delete where possible. 7. Check for duplicate objects on your system. Archive and delete where possible. 8. Re-organize your files to reclaim space. This can be done through the DSPFD *ALL/*ALL *MBR command to an output file. Run a query over the output file and check the number of deleted records. 9. IPL your system periodically. This reclaims temporary space and temporary objects created by the system. This is not that effective because the system will re-create most objects when your system is in production again. 10. Check the amount of data you keep in logs, messages and system journals. This can be done through the GO CLEANUP option 1 command. Be realistic when adjusting these attributes. 11. Check your output queues - WRKOUTQ. Archive and delete spooled files where possible. 12. After period-end processing reclaim your spool storage - RCLSPLSTG *NONE. This will reclaim spool storage created by period-end reports. This action can also be controlled through the QRCLSPLSTG system value. Be carefull to set it to *NONE. This will then cause the system to perform house keeping at a time you can't afford it. 13. Reclaim you DLOs. 14. Reclaim storage. I do this about every 6 months 15. Go though your objects and libraries with a fine toothcomb and try and identify objects that can be deleted. You might have to collect some history first to do this effectively. Try and spot files that are growing at a fast rate. This might be abnormal. 16. Archive historical data. This will require analysis and programming. We keep 5 year's data online, thereafter everything is archived. Hope this helps Best of luck
    5 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: