How many times over the years have I heard or seen a customer with several year-old spool data on OS/400 Output queues. This information is generally end-of-month or end-of-year reports required by auditors or executives to stay on the system. Along with these long time reports, there are a lot of other reports cluttering up the systems.
What’s the problem? First of all, this data may not be backed up properly. Have you ever tried to restore the data from your backup rules? Were you successful on the restore? Have you even tested recovering spool files from your backup? Remember, there is a parameter on the save commands that can backup spool data—the default is not to back up up this data. So the first issue is that this data is not safe.
The second concern is security. Did you know that any user profile with *SPLCTL can look at any spool file and the content inside? This also means they could accidently delete this data from the output queue. *SPLCTL is a little parameter on every user profile that is often given out with no concern for what it really means because it is harder to administer users if they don’t have the control. With spool control I can view old reports like payroll, human resource, and other data that you might not want the developers or operators to be able to see. So the second issue is that the data is not secure.
The third concern is performance of the system. Did you know that the commands like WRKACTJOB—or any program using job APIs—is impacted by spool data on an output queue? Those thousands of spool files are still considered to be taking up a job number on the system, and until you delete the spool files generated, the job is still considered on the system. It may not show up in WRKACTJOB but it still impacts this command as it must look at all jobs and then show only the active jobs. Jobs that are only on the output queue do impact the rest of the system’s performance. So the third issue with all of these spool files is performance.
These three concerns should be enough for you to ask the question, “What can I do about this issue?” We need the reports in case the auditors, government, or management team needs the reports. My suggestion is to look for a product that can archive this data off of the system and put it off to tape or Virtual Tape Library. There are many solutions today for the IBM i customer to take advantage of this technology. The good news with these solutions is that they provide history, and generally an end user interface, that allows the customer of the report to control their own destiny on the restore.
If you want to make your system more secure and better-performing you will need to change your strategy around this output. If you have not gotten burned yet by the accidental deletion: What happens if you have a disaster in this area?