The Four Hundred--Admin Alert: 5 Things to Do Before Adding iSeries Disk Capacity

All computer systems need lots of disk storage, and OS/400 is no different. But before you contact a reseller after your disk capacity breaks the 90 percent barrier, here are five procedures you can run to reclaim lost storage. While you may not be able to avoid a disk upgrade altogether, these tips may help you put it off for a while by restoring hard drive space you thought was gone forever.

If you're collecting performance data on your iSeries, be sure to delete old performance data files. When you enable automatic performance collection, there is a retention period parameter for how long you should keep performance data on the system. The value can be set from zero to 30 days, or the data can be kept permanently. Use the green-screen GO PERFORM command to get into the IBM Performance Tools for AS/400 menu. On that screen, take option 6, "configure and manage tools," then take option 2, "delete performance data." Fill in the name of the library that contains your performance data, and OS/400 will show you all performance data collections that exist on your system. Put a '4'=Delete in front of any collection that you no longer want to keep, press the ENTER key, and OS/400 will submit a batch job that deletes your old collections and frees up the storage space each collection was using. You should also note that IBM's Performance Tools (licensed product 5722-PT1) must be installed on your system in order to collect performance data.

Inventory any journal receivers you're using, and if you're able to, detach and delete unneeded receivers. In an earlier column about ODBC, I explained how to set up journal receivers so that OS/400 automatically deletes them once they are detached. If you haven't set up automatic deletion, examine your system journal receivers, detach any journal receivers that have become too big, and delete any detached journal receivers that are no longer needed. You may be surprised to see how much disk gets freed.

Reorganize large physical files to get rid of deleted records. By default, OS/400 retains all the space used by deleted records until the file is reorganized. Depending on file activity, this means that some physical files may be far larger than necessary because of deleted records that still occupy file space. To check if a file has a lot of deleted record space, you can run the Display File Description (DSPFD) command, as follows:

At the bottom of this display, you'll see the deleted record counts for each file member. If you see a large number of deleted records, you can eliminate the DASD space used by those records by running a Reorganize Physical File Member (RGZPFM) command on the file, as follows:

According to IBM documentation, running this command with the Key File (KEYFILE) parameter equal to *NONE will remove the deleted records and compress the active records in the file, so that all records are still stored according to their arrival sequence. The file is not reorganized with this parameter; it's just cleaned up and compressed without its deleted records.

If you want to reorganize, or resequence, the compressed file according to the keyed sequence of the physical file's access path, you can run the RGZPFM command with *FILE in the KEYFILE parameter:

When run this way, the arrival sequence of the reorganized records will be changed to match the keyed sequence access path of the file. Reorganizing by key can also speed up file access because it makes it easier to retrieve records by their keys.

You can also reorganize the file according to a logical file member key sequence by entering the logical file name, library name, and file member name of an associated logical file, as shown here:

The only downside to using *FILE or the logical file name parameters is that it destroys your ability to read the file in its original arrival sequence. Because the records are physically resorted to match the designated key value, the tradeoff in using these options is increased efficiency over preserving arrival sequence processing.

The other thing to watch out for is that RGZPFM locks the file being reorganized for the entire time that RGZPFM is running. Other processes that are trying to access the file will lock up or time-out. In addition, most of the common OS/400 commands that deal with file usage will not be able to run over the file while RGZPFM is running.

Consider setting up your physical files to reuse their deleted records when a new record is inserted. Each OS/400 physical file contains a parameter called Reuse Deleted Records (REUSEDLT). When set to *YES, REUSEDLT tells OS/400 that whenever a new insert request is logged against the file, it should use the space that is currently being allocated for deleted data entries. This parameter can be set when you create your physical file by using the Create Physical File (CRTPF) command, as follows:

Or REUSEDLT can be activated after a file has been created, by using the Change Physical File (CHGPF) command:

Note two things about this parameter. First, just like when you reorganize a physical file according to a file key, it effectively destroys the value of reading the file in arrival sequence. Because new files use deleted record space, they can be inserted at any point in the file where there is space, not just at the end, like arrival sequence. Second, the file must not have any locks on it when it is changed for REUSEDLT; otherwise, CHGPF may not run.

Occasionally run the Reclaim Storage (RCLSTG) command on your system. RCLSTG attempts to validate and reclaim orphaned, damaged, and incomplete objects on the system, thus freeing up OS/400 storage. This is a good command to run every once in a while, but since it needs to run on a restricted system, it may not be practical to run it every week. For more information on what RCLSTG does, and the best practices to run it, see "Tips on Running RCLSTG."