There are many reasons why you should routinely clean up printer output, also known as spooled files, from your iSeries system. Spooled files take up disk space, they lead to clutter that makes it harder to find the output you want, and -- perhaps most important -- they take up active system resources.
Did you ever notice that when you run the WRKACTJOB (Work with Active Jobs) command, the number of jobs shown is different than the number of jobs shown via the WRKSYSSTS (Work with Disk Status) command? If you look at the help text for the number of active jobs for the WRKACTJOB command, it says, "The current number of jobs active in the system (jobs that have been started but have not yet ended), including both user and system jobs." In other words, the count on this screen is for jobs that are currently running. The help text for the number of jobs on WRKSYSSTS says, "The total number of user and system jobs that are currently in the system." The total includes the following:
- All jobs on job queues waiting to be processed
- All jobs currently active (being processed)
- All jobs that have completed running but still have output on output queues
The last bullet shows why spooled files can be a problem. The system has to track this output, and has to keep around information about the jobs that produced the output.
All jobs in the iSeries -- including jobs that have been submitted but are waiting on job queues, currently running jobs, and jobs with spooled output -- are tracked in an internal structure known as the Work Control Block Table. This structure keeps information pertinent to all of the types of jobs listed above. Usually, the largest percent of entries in the Work Control Block Table are jobs that have completed but still have spooled output.
|
|
 |
Since each entry in the table requires a certain amount of space, the more entries that exist, the more disk and memory resources are needed. Also, certain functions in the system related to jobs must access the Work Control Block Table. In some cases, they must walk through the entire table.
If you have ever heard that the WRKACTJOB command is a bad command for a lot of people to run at once or that it is a system hog, this is the reason why. When you invoke WRKACTJOB, it has to walk through the entire Work Control Block Table to gather the information it needs to display. A classic example is when a system slowdown has occurred and a whole bunch of people invoke WRKACTJOB all at once trying to figure out what is going on. All of the sudden the system slows down even more because of the resource demands of all those WRKACTJOB commands running at once.
It follows then that cleaning up old spooled files that are no longer needed (or not creating them in the first place) can help you avoid the extra overhead of managing the associated jobs. To prevent job logs from being created, you can set the Message Logging parameter in job descriptions to (4 0 *NOLIST), which will prevent jobs using the job description from creating a job log if it ends normally. Doing so can prevent a lot of clutter.
You should also use the automated cleanup options available via GO ASSIST to clean up job logs and other system output after a specified period of time. If your users need to keep output indefinitely, they can either print it or copy it to their PC using iSeries Navigator. From their PC, their output can be burned onto a CD.
Finally, you should periodically go through all output queues and clean up old spooled files that are not needed. Once you become familiar with the kind of output being created on your system, you might want to write some CL code to automate the cleanup process and run it from the job scheduler.
Although the overhead associated with spooled files is not terribly bad, it is best to keep those files cleaned up. IBM has provided some tools such as GO ASSIST to help, but some of the work will be up to you and your users. Like any other cleanup task, if you do it a little at a time, it is easier than waiting until the mess is out of control.
-----------------------------------
About the author: Dan Reusche is a senior systems administrator at Think Federal Credit Union in Rochester, Minn. He has worked with the IBM AS/400 and iSeries platform since 1988, when he worked at the IBM Rochester Development Lab and support of AS/400 systems used within IBM. You may contact him at dreusche@chartermi.net.
