Admin Alert: Corralling i/OS Storage Hogs, Part 1

March 2, 2011 Joe Hertvik

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.

Excessive spooled files and other system objects
Walking Dead libraries
Just In Case files
Large files that need reorganization
Files with obsolete members
Cleaning up utility program data
Controlling your journaling

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.

Time cleanup starts each day–Put in a time if you want the system to clean up storage each day (you do) or set it to *NONE to turn clean up off.
User messages–Specifies how many days you want to keep messages in each user profile’s message queue.
System and workstation messages–Specifies how many days you want to keep informational system messages and messages in the workstation message queues.
Critical system messages–Specifies the number of days you want to keep critical system messages in the QSYSMSG message queue. All the messages that are considered critical on your system are kept here, including serious storage condition messages, hardware error messages, and messages that occur whenever the system disables a user profile. These messages are different from the standard inquiry messages you get when a printer has a form change, a program crashes, etc. The initial value for Critical system messages is *KEEP, which means i/OS will never delete messages from QSYSMSG. This means you may still have critical messages sitting on your system from the time your system was installed, but you can change this value to any number of days that you want.
Job logs and other system output–This is the critical value that may hide a storage hog. It controls how long system spooled files, such as you might see in the QEZJOBLOG (job logs), QPPGMDMP (program dumps), and QEZDEBUG (debug traces) output queues, are kept on the system. When set to a number between 1 and 366 days, the system will delete job logs and other system spooled file output as it ages. All of which will help keep your system storage down. If this number is set to an unusually high value, such as 366 days or *KEEP, all the job logs and other system output will remain on your system for a very long time, gobbling up disk space. In my experience, I haven’t found too much sense in keeping these spooled files for more than a month. However, your shop may need to keep them for a longer period so set these values as needed.
System journals and logs (SYSLOG)–Specifies how long you want to keep system journals, history files, problem log files, and alert databases. I’ll get into controlling journal receivers next issue but this value can also be set to keep your system storage down.

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.