Programming for performance is a vast topic that has many points of view as to what is right and what is not. One little-considered area is "seek time"--the time it takes for the iSeries or AS/400 to physically locate and retrieve the requested data. One generality is that the more stuff you have to seek through, the longer the seek will take. The corollary is the greater the percentage of free space, the better the performance. Fortunately, there are many things you can do, large and small, to free up space on your hard drives.
Let's start with the big and difficult:
Reclaim Storage (RCLSTG)--This has several disadvantages:
- A dedicated system is required--nothing else can run.
- The job may take several hours.
- The overall result may be nothing.
On the other hand, RCLSTG may uncover some very serious problems. If you have a bad area on disk, RCLSTG will attempt to recover the data and place the data in a new area. RCLSTG will identify orphaned objects that are not a part of any library. If you are having problems, RCLSTG can free up a significant amount of disk space. It is advisable to run RCLSTG once a month, even if it means kicking the users off the system. You might be surprised by what you find.
Reorganize Files (RGZPFM)--This command is especially effective when using the KEYFILE(*FILE) parameter on indexed physical files. The space for all deleted records in the file will be purged, and the data in the file will be physically arranged in key sequence. The larger the file, the greater the benefit. The greater the volatility, the greater the benefit. I have heard arguments against reorganizing because files were very large and constantly in use. I don't care. It's like going into battle with a rusty gun. You know the gun needs cleaning, but you're using it so much you won't take the time to clean it...until it backfires! Not taking the time to reorganize your data is the AS/400 equivalent of the rusty gun. One day, your performance will backfire.
Regenerate Journal Receivers (CHGJRN *GEN)--Even if you are not using journals, many system programs do. Use the DSPOBJD ALL/ALL *JRNRCV command to see the size of existing journal receivers. These can be huge! Generating a new receiver for the journal and then deleting the old receiver can save a significant amount of space.
Now for the little piddly stuff:
Work with Alerts (WRKALR)--Alerts can be important. However, most of the time they are not and can be deleted. Use the WRKALR command to display your alerts and determine what can be removed.
Work with Problems (WRKPRB)--If you are not using ECS or the service director, problem records may not have any meaning for you. The system will allow you to delete any problem records over a month old. You may want to play with the system value that controls this default time period.
Clear Message Queues (CLRMSGQ)--Message queues can accumulate a ton and a half of messages. Periodic cleansing can cut the accumulation. Certain system message queues are more prone to message clutter than others. These include QSYSOPR, QPGMR, QTCP, QSRV, QSECOFR, and others.
Delete old system logs--This can be accomplished by typing WRKOBJ QSYS/QHST* *FILE and pressing Enter. All but the last entry may be deleted. The size of the system log is controlled by a system value.
Delete spool files--When a determination is made as to which spool files are safe to delete, then they should be deleted via WRKSPLF *ALL. The occasional system dump can occupy an awfully large amount of space. Run RCLSPLSTG *NONE afterward to reclaim the space that the spool files were using.
These are just some of the things that you can do to free disk space. You can automate many of these tasks by going to the assistance menu (GO ASSIST) and selecting the clean-up options. Other tasks are only pertinent to the individual shop. What may be a regular garbage cleanup program in one shop could be a disaster of deleted valuable objects in another. Some shops place a great deal of info on the IFS, while other shops hardly touch the IFS. The best judge of pertinence versus irrelevance is likely the one who is most familiar with the system. On that note, I'm gonna find my own space.