AS/400-iSeries Starter Kit

OS/400 is a sophisticated operating system that tracks almost everything that happens on the system. This tracking is good, but it results in a messy by-product of system-supplied database files, journal receivers, and message queues. Users add to the clutter with old messages, unused documents, out-of-date records, and unprinted spool files. If you do nothing about this disorder, it will eventually strangle your system. But you can implement a few simple automated and manual procedures to keep your disk storage free of unwanted debris.

Automatic Cleanup Procedures

In August 1990, IBM introduced Operational Assistant (OA) as part of the operating system. Today's OA functions include automatic cleanup of some of the daily messes the AS/400 makes. OA's automatic cleanup is a good place to start when you're trying to clean up your AS/400's act.

To access the OA Cleanup Tasks menu (Figure 12.1), you can type GO CLEANUP or select option 11 ("Customize your system, users, and devices") and then option 2 ("Cleanup tasks"), both from the OA main menu. You can use this menu to start and stop automatic cleanup and to change cleanup parameters. Option 1, "Change cleanup options," gives you the Change Cleanup Options display (Figure 12.2). (To bypass these menus, just prompt and execute the CHGCNLUP (Change Cleanup) command.) Note that you must have *ALLOBJ, *SECADM, and *JOBCTL authorities to change cleanup options. If option 1 does not appear on the Cleanup Tasks menu, you do not have the proper authorities.

Using the Change Cleanup Options screen, you can enable the automatic cleanup function and specify that cleanup should be run either at a specific time each day or as part of any scheduled system power-off. Specify *YES for the ALWCLNUP parameter to tell the system that you want to enable automatic cleanup. For STRTIME, you can enter a specific time (e.g., 23:00) for the cleanup to start, or you can enter *SCDPWROFF to tell the system to run cleanup during a system power-off that you've scheduled using OA's power scheduling function (the cleanup will not be run if you power off using the PWRDWNSYS (Power Down System) command or force a power-off using the control panel). Returning to the Cleanup Tasks menu, execute option 2, "Start cleanup at scheduled time," and your AS/400 will execute the cleanup each day at the specified time. Although it is ideal to run cleanup procedures when the system is relatively free of other tasks, it is not a requirement; and OA's cleanup will not conflict with application programs other than competing for CPU cycles.

The other parameters on the Change Cleanup Options screen let you control which objects the procedure will attempt to clean up. Each parameter allows a value of either *KEEP, which tells the system not to clean up the specified objects, or a number from 1 to 366 that indicates the number of days the objects or entries are allowed to stay on the system before the cleanup procedure removes them. The table in Figure 12.3 lists the cleanup options and the objects that they automatically clean up.

Look closely at the list of objects cleaned up by the "Job logs and other system output" option. When you activate this option, the system places all job logs into output queue QUSRSYS/QEZJOBLOG and all dumps (e.g., system and program dumps) into output queue QUSRSYS/QEZDEBUG. The cleanup procedure removes from these output queues any spool files that remain on the system beyond the maximum number of days.

OS/400 uses a variety of database files and journals to manage operating system functions (e.g., job accounting, performance adjustment, SNADS, the problem log). Regular, hands-off cleanup of these journals and logs is the single most beneficial function of the automatic cleanup procedures; without this automatic cleanup, you have to locate the files and journals and write your own procedures to clean them up. This, along with the possibility that IBM could change or add to these objects in a future release of OS/400, makes this cleanup option the most helpful.

For OfficeVision/400 users, the "OfficeVision/400 calendar items" option is an effective way to manage the size of several OfficeVision production objects. This option cleans up old calendar items and reorganizes key database files to help maintain peak performance.

If you ever want to stop the automatic daily cleanup, just select option 4, "End cleanup," to stop all automatic cleanup until you restart it using option 2.

Manual Cleanup Procedures

OA's automatic cleanup won't do everything for you. Figure 12.4 lists cleanup tasks you must handle manually. By "manually," I mean you must manually execute commands that clear entries or reorganize files, or you must write a set of automated cleanup tools that you can run periodically or along with OA's daily cleanup operations.

Save security audit journal receivers. If you activate the security audit journaling process, the receiver associated with QAUDJRN (the security audit journal)
will grow continuously as long as it's attached to QAUDJRN. In fact, if you select all possible auditing values, this receiver will grow rapidly. As with all journal receivers, you are responsible for receiver maintenance. Here are my recommendations.

First, do not place audit journal receivers into library QSYS (QAUDJRN itself must be in QSYS, but receivers can be in any library and in any auxiliary storage pool). Place them in a library (e.g., one called AUDLIB) that you can save and maintain separately. Each week, use the CHGJRN (Change Journal) command to detach the old receiver from QAUDJRN and attach a new one.

Make sure your regular backup procedure saves the security journal receivers (only detached receivers are fully saved). If you specify "System journals and system logs," OA's automated cleanup operation deletes old security audit journal receivers that are no longer attached to the journal. Your backup strategy should include provisions for retaining several months of security journal receivers in case you need to track down a security problem.

Do an IPL regularly. Perform an IPL regularly (e.g., weekly or bimonthly). An IPL causes the system to delete temporary libraries, compress work control blocks, and free up unused addresses. The result is that more disk storage becomes available, and performance improves.

During an IPL, the system also closes job logs and opens new ones. This housekeeping especially benefits system-supplied jobs (e.g., QSYSWRK, QSYSARB, QSPLMAINT), whose job logs can grow quite large between IPLs. After IPL, system jobs require less time to write to the end of the job log, giving performance a boost. The more active your system, the more frequently you need to IPL -- on very active systems, you should IPL at least once a week.

Reclaim spool file storage. Like the S/38, the AS/400 has an operating-system-managed database file that contains a member for every spool file (e.g., job log, user report, Print key output) on the system. When you or the system creates a spool file, OS/400 uses an empty member of the spool file database (which is maintained in library QSPL) if one is available; otherwise, OS/400 creates a member. Whenever a spool file is deleted or printed, the operating system clears that file's database member, readying it for reuse. But even empty database members occupy a significant amount of space. If you create many spool files, this database can grow like Jack's beanstalk (I have seen QSPL grow to 150 MB).

Again like the S/38, the AS/400 checks all empty QSPL database members at every IPL and deletes those that have been on the system for seven or more IPLs. But since V1R3 of OS/400, the AS/400 has provided two additional methods of cleaning up these empty database members.

The first method is to use system value QRCLSPLSTG, which lets you limit the number of days an empty member remains on the system. Valid values include whole numbers from 1 to 366; the default is 8 days. When an empty member reaches the specified limit, the system deletes the member. *NONE is also a valid value, but it is impractical because it causes the system to generate a new database member for each spool file you create, thus overburdening the system and hurting performance. A value of *NOMAX tells the system to ignore automatic spool storage cleanup.

The second new housecleaning method for spool files is to execute the RCLSPLSTG (Reclaim Spool Storage) command. If you want to control spool file cleanup yourself rather than have the system do it, you can enter a value of *NOMAX for system value QRCLSPLSTG and then execute the RCLSPLSTG command whenever necessary.

Reclaim storage. You should use the RCLSTG (Reclaim Storage) command periodically to find damaged or lost objects and to ensure that all auxiliary storage is either used properly or available for use. Unexpected power failures, device failures, or other abnormal job endings can create unusual conditions in storage, such as damaged objects, objects with no owners, or even objects that exist in no library (i.e., the library name is absent).

During a reclaim of storage, the system puts any damaged and lost objects it encounters into the recovery library, QRCL. After storage is reclaimed, you should look in QRCL, move any objects you want to keep to another library, and delete any remaining objects. Also, normal operations use a portion of auxiliary storage for permanent and temporary addresses. The RCLSTG command recovers and recycles addresses that the system used but no longer needs.

You should run RCLSTG every six months or whenever you encounter messages about damaged objects or authority problems with objects. You also should monitor the permanent and temporary addresses the system uses by executing the WRKSYSSTS (Work with System Status) command. When WRKSYSSTS shows that permanent and temporary addresses exceed 20 percent of the available addresses, execute the RCLSTG command.

Keep in mind that you can execute RCLSTG only when the AS/400 is in restricted state (i.e., all subsystems must be ended, leaving only the console active). You can also use OA's disk analysis reports, which list the space taken up by damaged objects, objects without owners, and objects without libraries, to determine when you need to do a RCLSTG. For more information about the OS/400 RCLSTG function, see the Basic Backup and Recovery Guide (SC41-0036-01).

Remove unused licensed software. Another way to reclaim disk storage is to remove unused licensed program products (e.g., product demos, old third-party products you no longer use, and IBM products such as the OS/400 migration aids, once you're done with them). After saving libraries and objects you no longer need, delete the products you no longer need (you can use the GO LICPGM command to access the IBM licensed products menu).

Clean up user output queues. What about user-created spooled output? OA's cleanup addresses job logs and certain service and program dump output. But when users create spool files, these files also stay on the system until the user prints or deletes them. You need to either monitor user-created output queues or have users monitor their own. One tool some AS/400 customers find helpful is DLTOLDSPLF, a utility in library QUSRTOOL that finds and moves or deletes all spool files older than a specified number of days.

Reset message queue sizes. User-created messages can also add to the clutter on the AS/400. As messages accumulate, message queues grow to accommodate them; but queues don't become smaller as messages are removed. Although OA's automatic cleanup clears old messages from user and workstation message queues, it doesn't reset the message queue size. To reset the queue size, you must use the CLRMSGQ (Clear Message Queue) command to completely clear the message queue. Again, you can perform this task manually for specific message queues, or you can automate the process by writing a program.

Clear save files. If you frequently use save files for ad hoc or regular backups, you may want to define a manual or automated procedure to periodically clear those save files and reclaim that storage. After you save a save file's data to tape or diskette, clear the file by executing the CLRSAVF (Clear Save File) command.

Manage journal receivers. If you use journaling on your system, you need to manage the journals you create. As with the security audit journal receivers, detach and save receivers as part of your normal backup and recovery strategy. Then you can delete receivers you no longer need.

For more information about journaling and managing journals and receivers, refer to the Programming: Backup and Recovery Guide (SC41-8079).

Delete old and unused objects. Old and unused objects of various kinds can accumulate on your system, unnecessarily using up storage and degrading performance. You should evaluate objects that are not used regularly to determine whether or not they should remain on the system. Remember to check development and test libraries as well as production libraries.

Since V1R3, the description of each object on the system includes a "last used" date and time stamp, as well as a "last used" days counter. The object description also contains the "last changed" date and time as well as the "last saved" date and time.

Beginning with V2R2, you can use the Disk Space Tasks menu (Figure 12.5) to collect information about and analyze disk space utilization. You can call this menu directly by typing GO DISKTASKS, or you can access it through the main OA menu. As you can see, the menu options let you collect and print disk space information as well as actually work with libraries, folders, and objects.

When you select option 1 to collect disk space information, you'll see the prompt in Figure 12.6. You can collect disk space information at a specified date and time by selecting option 1. Selecting 2 or 3 tells the system to collect information at the specified interval.

Whichever option you choose, the system collects information about objects (e.g., database files, folders (including shared folders), programs, commands) and stores it in file QUSRSYS/QAEZDISK. You can then select option 2 on the Disk Space Tasks menu to print reports that analyze disk space usage by library, folder, owner, or specific object. Or you can print a disk information system summary report. Because the data is collected in a database file, you can also perform ad hoc interactive SQL queries, use Query/400, or write high-level language programs to get the information you need.

Purge and reorganize physical files. An active database environment can contribute to the AS/400's sloppy habits. One problem is files in which records accumulate forever. You should examine your database to determine whether any files fit this description and then design a procedure to handle the "death" of active records.

In some situations, you can simply delete records that are no longer needed. In other situations, you might want to archive records before you delete them. In either case, you certainly won't want to delete or move records manually; instead, look for a public-domain or vendor-supplied file edit utility or tool.

Deleting records does not increase your disk space, however. Deleted records continue to occupy disk space until you execute a RGZPFM (Reorganize Physical File Member) command. You could write a custom report to search for files with a high percentage of deleted records and then manually reorganize those files. Or you could go one step further and write a custom utility that would search for those files and automatically reorganize them using the RGZPFM OS/400 command.

Clean up OfficeVision/400 objects. OfficeVision/400 can devour disk space unless you clean up after it religiously. Encourage OfficeVision/400 users to police their own documents and mail items and to delete items they no longer need. You can use the QRYDOCLIB (Query Document Library) command as a reporting tool to monitor document and folder maintenance. You might also want to limit the auxiliary storage available to each user by using the MAXSTG parameter on each user profile.

Figure 12.7 lists the OfficeVision/400 database files you should reorganize regularly (every little bit helps with the OfficeVision performance hog!). You will probably want to write a CL program that reorganizes these files and run that program when OfficeVision is not in use.

Enhancing Your Manual Procedures

You can handle many of the manual tasks I've mentioned by using the QEZUSRCLNP job to incorporate your own cleanup programs and commands into OA's automatic cleanup function. QEZUSRCLNP is essentially an empty template that gives you a place to add your own cleanup code. Every time OA's automatic cleanup function is run, it calls QEZUSRCLNP and executes your code.

To add your enhancements to QEZUSRCLNP, first use the RTVCLSRC (Retrieve CL Source) command to retrieve the source statements for QEZUSRCLNP (Figure 12.8) from library QSYS. Then insert your cleanup commands or calls to your cleanup programs into the QEZUSRCLNP source. Be sure to add your statements after the SNDPGMMSG (Send Program Message) command for message CPI1E91 to ensure that, after your cleanup job has ended, the system sends a completion message to the system operator message queue.

Finally, compile your copy of QEZUSRCLNP into a library that appears before QSYS on the system library list. (You can modify the system library list by editing the QSYSLIBL system value.) I caution you against replacing the system-supplied version of the program by compiling your copy of QEZUSRCLNP into QSYS. By using a different library, you can preserve the original program and avoid losing your modified program the next time you load a new release of the operating system.

In OA's automated cleanup function, the AS/400 gives you the services of a maid to solve some simple cleanup issues. Use the function. But your cleanup shouldn't stop there. You also need to develop and implement procedures to maintain system-supplied and user-defined objects, such as spool and save files.