Admin Alert: Corralling i/OS Storage Hogs, Part 1
March 2, 2011 Timothy Prickett Morgan
Last year, I wrote an article on finding and expelling i/OS storage hogs. Since then, I’ve pinpointed some other items that illustrate how Power i system storage fills up unnecessarily, leaving you contemplating buying additional disk drives when all you really need is a good housecleaning. This week and next, I’ll expand on my storage hog list to help you keep your storage problems under control.
The Big Seven Storage Hogs
When looking for ways to reclaim disk storage, I usually focus my attention on the big seven culprits of unnecessary storage consumption.
Let’s look at each of these disk hogging factors in turn and see what you can do to control them.
Hog #1: Excessive spooled files and other system objects
Some shops have an unnatural attraction for hanging on to almost any spooled file they have ever produced, especially job logs. The solution to unnecessary spooled files and other objects is twofold. First, carefully examine your system cleanup options inside the Cleanup Tasks (GO CLEANUP) menu. Take option 1 off this menu (Change Cleanup Options) to get to the following screen.
These options control how disk consuming system objects (including spooled files) are automatically cleaned off the system.
Step number one on this screen is to make sure that the Allow automatic cleanup setting is set to ‘Y’ (Yes). The default value is ‘N’, but the system will set this parameter to ‘Y’ during a scratch install. If it isn’t turned on, turn it on. The next step is to go through each option on this screen so the operating system knows what to get rid of when it runs its daily clean up routine. Here’s what the options do.
You’ll generally get the biggest storage-saving bang for your bucks setting the system and workstation messages and job logs and other system output values as low as you possibly can.
The second spooled file control issue deals with excessive user-generated spooled files. As far as I know, there is no i/OS setting in V6R1Mx or V5R4Mx to control when the system should delete aged user-generated spooled files. User generated spooled files can cause a problem if they are written to an output queue that is seldom cleared (such as a fax queue or an queue that’s used for generating email reports) or the files are printed with the Save File spooled file attribute set to *YES (save), causing the spooled file to remain on the output queue in save status after printing. For situations like these, you either have to clear the output queues yourself or come up with a routine or third-party software package that deletes user-generated aged spooled files for you. Check out this article for an example of how you might setup your own routine to delete aged user-generated spooled files and regain system storage.
Hog #2: Exercising the Walking Dead (libraries)
Here I’m referring to software and data libraries that are saved before replacement and never deleted. For example, let’s say you installed a credit card software upgrade to the CRTCRD library but you wanted to save a copy of the old library in case the installation went bad. So you copied the old library to the CRTCRDXXX library so that you could update the existing CRTCRD library. The new installation goes great but somehow you never delete the old CRTCRDXXX library from your system, so you’re carrying two program libraries for that product.
Worse, you may do the same thing when you updating or making mass file changes to one of your data libraries. As happens with software libraries, you make a copy of the data library in case something goes wrong and then forget about it. Just like that, you’ve doubled the amount of disk storage for that particular data set.
My recommendation here is to review all your libraries and if you notice a Walking Dead library that you no longer need, back it up to media, and then delete it. Taking a backup before deletion ensures that if you delete the library in error, you can bring it back as needed.
To find Walking Dead libraries, look for libraries that have literals like ‘OLD’, ‘XX’, or ‘SAV’ tacked on to the end of their original library name. Libraries with funny names that start with a programmer’s initials are also a dead giveaway (e.g., JHCRTCRD instead of CRTCRD).
Hog #3: Just In Case files
Similar to Walking Dead data libraries, Just In Case files are usually taken before a file change is enacted. For example, if you’re changing a file format for the SALEHIST file you may make a copy of the file called SALESHSTXX. Like Walking Dead libraries, Just In Case files protect you against mistakes. However, people don’t always get rid of their Just In Case files and they frequently wind up taking up more room on the system.
Just In Case files can be harder to find than Walking Dead Libraries, but they can return more system storage when deleted. Similar to the dead libraries, Just In Case file names may contain programmer initials, give away literals (‘OLD’, ‘XX’, ‘SAV’), or numbers (SALESHIST1, SALESHIST2, etc.). You may also be able to use some of the techniques I’ll talk about next issue for spotting large storage hogging backup files.
Finding More Storage Hogs
Next issue, I’ll review the rest of the list and show you where you may be able to pick up some more storage in a pinch. See you in 14.