When in doubt, throw it out. Back it up first, but yes…throw it out.

Irony can be a funny thing. Last week, with the subject matter of this article in my mind, I ran into a sticky situation when our little AS/400 Model 170 started sending messages to the QSYSOPR message queue stating that "a serious storage condition may exist." We do a nightly backup of production data on this machine to save files and then transfer them to our primary IBM i 515 server. Eventually, they get moved to the nightly LTO.

Bad Practices Can Bite You in the End

It turned out that a program was appending our 3 MB inventory file to a library every day for the last seven years, and the results were starting to show in our nightly backup routine. In the end, the amount of data being backed up and transferred was close to 10 GB, roughly 25 percent of our total disk space of that server. During the day, the system hovered around 65-70 percent utilization, but when the disk approached about 95 percent utilization during the backup, it had a little trouble (to say the least) in transferring all that data to the 515.

After I spent about two hours manually purging inventory data from years gone by, the backup eventually shrank to about 30 minutes and the data transfer to about 90. I've since altered the guilty program to use a more "disk-friendly" approach. It's a much more efficient solution, and I've got a recent real-world example to write about here as a warning.

You may not know about everything going on with your system, but you need to be able to identify problems like this and put standards and best practices in place to avoid similar problems down the road.

Down to Business…What Do We Throw Out?

You won't know what to clean up unless you know what garbage is on your system. The first step is to do a little analysis.

Two great commands are Retrieve Disk Information (RTVDSKINF) and Retrieve Directory Information (RTVDIRINF). RTVDSKINF will generate a physical file (by default QAEZDISK in QUSRSYS) that contains information about objects in the qsys.lib file system. RTVDIRINF has a similar function; however, I like it much more because it has the ability to generate a listing of every object in all file systems.

Now that you have a couple of databases, you can query them to identify files or libraries that are either unneeded or too large.

I have a great little job that runs every night. I schedule a RTVDSKINF job and then have a couple of queries that pare down and export the data to another physical file to show me the total size of each library. By querying this file, I can tell which libraries are growing the fastest over the past weeks, months, or years.

I also schedule a RTVDIRINF job each night and query the resulting physical files to get information on our Domino directories (number and size of all mail files), IFS usage by user profile, a top 10 list of objects on the IFS in descending order of size, and a few other nuggets.

Automatic Cleanup

From a command line, type "go cleanup." The Cleanup Tasks menu gives you the ability to schedule deletion of job logs, history logs, messages, OfficeVision/400 objects, and journal receivers based on how many days old they are. This is basic maintenance at its finest.

PTF Save Files and Cover Letters

There are many online references for deleting long-since-applied PTF save files using the Delete File (DLTF) command. Don't do it! If you do this, the system PTF functions won't realize that the save file has been deleted. It's best to use the Delete PTF (DLTPTF) command or use the options in Navigator to clean up your old fix save files and cover letters.

Miscellaneous Save Files

Do a search for save files that aren't needed anymore. Use the command WRKF FILE(*ALL) LIB(*ALL) FILATTR(SAVF) or query the output from RTVDSKINF I mentioned above for save files. I prefer the query option as you have the ability to sort by the size of the save files you can clean up without having to view each object's description.

Have a look at what you find. If you see anything you think you don't need, you're probably right. Back those up to tape just in case and then blow them away using the DLTF command, unless of course they are PTF save files. Typically, the usual orphaned save file has been either left there by an installer program and never properly cleaned up or created by someone as a temporary backup device and never cleaned up.

Also, if you find vendor-supplied objects, please contact the vendor about them as they may be actually needed as part of the vendor's solution. Hold their feet to the fire on garbage collection, though…it's your i, not theirs.

Old Journal Receivers: Big, Static Files Are Not Your Friend

Come on. If you wanted to find something devious, you'd have found it by now. If you have the luxury, pick a safe checkpoint and delete everything older than that. If your company is required by law to keep journal receivers, then they can be archived to external media (tape, DVD, etc.) or a storage server.

Licensed Programs: Do You Really Need That COBOL Compiler for System 36?

Well, some of you may. View your installed licensed programs by using the command GO LICPGM and taking option 10. This will list your installed licensed programs. Review, back up, and delete what you don't need.

If you run Lotus Domino servers on i, you may have previous releases of Domino installed even though you've long since upgraded all of your active servers. As Domino allows for multiple different versions on i, it also allows for lax administrators to keep versions available long after upgrade.

Performance-Monitoring Software

Check the status of PM for i, Collection Services, or any third-party performance-monitoring tool. Turn it off or limit the data collection if you don't need to have it running at full tilt. While these are awesome tools that can serve a very valuable purpose, you may want to check your configuration to ensure you're not unnecessarily monitoring things and causing additional disk/processor overhead. If you don't need to run PM for i or Collection Services, then clear libraries QMPGDATA and QPFRDATA, respectively, to regain space as they can get pretty huge.

Get Rid of White Space

Get an idea of how much physical file white space is hijacking your disk real estate. Use the following command to generate a listing of physical files on your system and information about the file contents:

DSPFD FILE(*ALL/*ALL) TYPE(*MBR) OUTPUT(*OUTFILE) FILEATR(*PF) OUTFILE (testlib/testfile)

On the output file testfile, you can run a quick query to filter files with deleted records and then use some simple math based on file size to get a fairly accurate representation of how many GB of white space you have on your system. Now you'll know how much space you'll get back by running a Reorganize Physical File Member (RGZPFM) command on this list of files to recover white space from deleted records. In addition, you can change these physical files to reuse deleted records.

Monitor and Manage Your IFS Storage Accordingly

If you're using your IFS as a file server for your users, you should be setting a storage quota for each one of them. Actually, if you want to keep things tidy no matter what file systems users are allowed to write objects to, you should implement a user storage quota. Allowing users write access to the IFS allows them to jump from 5 MB to 5 GB of used space quite easily. This can get quite hairy if you don't manage it properly.

The age of objects matters, too. Our information systems computer usage policy dictates that user-generated IFS files older than two years are to be deleted each year. This ensures that people are not using the IFS as a file graveyard. Every year, we run a scheduled purge of the IFS area set aside for users. Everyone is given fair warning to back up their static files to DVD a few weeks in advance.

If purging by object change date, you should use the RTVDIRINF command on a user portion of the IFS. This will get you a list of objects so you'll have an idea of how much space you'll recoup when you're done. Writing a purge program in RPG is very simple. You just read the contents of a RTVDIRINF output file, and if the object's last-change date is older than two years, delete the file.

If you don't have one already, a great idea would be to create a computer usage policy and require users to read it, sign it, and abide by it. Then they can't say they weren't told not to upload 2-3 GB of pictures from their Disney World vacation to the IFS after the fact.

Clean Up Old or Unused User Profiles

Review objects owned by these profiles using command Work with Objects by Owner (WRKOBJOWN). Delete the objects you can and assign ownership of other objects to someone else. Then delete the profile.

Quietly Unload Your Virtual Optical Drive and Don't Tell Anyone

Have you ever done a PTF application via a virtual optical drive? Ever leave all the images on there and forget about them? No one wants to admit it, but we've all done it.

Have a look using this command:

WRKIMGCLG *ALL

I bet some of you find a CD image or two loaded and ready to roll.

I'm certain you all checked, though. Moving on…

Reclaim Storage

You can use the Reclaim Storage (RCLSTG) command as part of a cleanup operation as it validates every header and pointer, finds orphaned objects, corrects objects that were incompletely updated, and deletes unusable objects or fragments, among other things.

IBM is hesitant for people to run this command so I'll offer you the disclaimer. However, if the command exists, there's a purpose for it.

Reboot It!

I tell my customers, "When in doot, reboot!" I'm Canadian, by the way, and that is a spelling error used for a cheap joke. Hopefully, but not likely, you're laughing.

If you've got the luxury, give your system an IPL whether it needs it or not every once in a while. Not only does an IPL do some basic cleanup, but it's just good business to know you always have a clean and working startup program. For instance, I know of a company that hadn't done an IPL in close to two years and never thought to update their startup program to initialize certain elements for their recently acquired ERP app. They found out the hard way when they brought the system back up after adding memory one weekend and the ERP-specific dedicated batch subsystem wasn't running. No errors in the system operator queue, so the IT folks left the building just as everything started to fall apart on the production floor. It's a good point, but I digress.

Be Proactive!

While this is by no means a full list of things to do for a system cleanup, it's definitely a good start. It's far too easy to wait until there's a problem to take action. However, doing that may cause unnecessary downtime and unscheduled maintenance work for you.

It's much better to be proactive: automate cleanup processes, set and enforce rules for users and IT staff, and do regular manual cleanup tasks.