Have you ever worked with spooled files, whether using WRKSPLF or WRKOUTQ, and noticed the output queue or spooled files listed have a status that doesn’t make sense? For example, the spooled file status is *WTR, but no spool writer is started to the output queue the spooled files are on? This should be a fairly rare event, but at times the abnormal ending of jobs may cause this situation. Introduced in the IBM i 6.1 release, a new command, Start Spool Reclaim (STRSPLRCL), can repair output queues and spooled files that are left in one of these unrecoverable states.
In the past, a spool “fixup” program could be called that ran through all of the spooled files on the system and recovered some of these situations, but it could be very long running on systems with many spooled files and it was pretty limited in what it fixed. Start Spool Reclaim has enhanced support for fixing up spooled files and output queues with bad statuses. The command itself has only two parameters. The first is the Output queue (OUTQ) parameter, which allows you to specify a specific output queue, a generic list of output queues, or all output queues in one or more libraries. The other parameter is the ASP group (ASPGRP) parameter, which allows you to run the command against either *SYSBAS (the system ASP and all user ASPs), the thread’s library name space, the thread’s current ASP group, or a specific independent ASP group. Using these parameters allows the user to target only the output queues on which he notices abnormalities. This is especially valuable when the abnormal ending of a writer left a specific output queue or the spooled files on that output queue with invalid statuses.
The Start Spool Reclaim command itself doesn’t do the real work. The real work is handled by new system jobs introduced in 6.1. The QSPRC00001 job is started during IPL of the system. Also, QSPRCxxxxx jobs (where xxxxx is the ASP number of the primary ASP in an ASP group), are started for each ASP group when they are varied on. The STRSPLRCL command simply signals an event to one or more system jobs to begin fixing the output queues and spooled file statuses in the background. It then returns to the user indicating which system jobs have been sent the request. If the output queues being fixed are in a library in the system ASP, the job sends the request to the QSPRC00001 system job. If the output queues being fixed are in a library on an independent ASP, the request is sent to the QSPRCxxxxx job where xxxxx is the ASP number of the primary ASP in the ASP group. If the request involves output queues in both places, a request is sent to each. The system jobs process the output queues and the spooled files on those output queues fixing up any wayward statuses and correcting what is shown for the number of spooled files on an output queue. A message (CPC3309) indicating successful or unsuccessful completion is sent to the QHST and QSYSOPR message queues by each spool system job.
One additional special function should be noted here as well. If the user specifies *ALL/*ALL for the output queue parameter and *SYSBAS or * is specified for the ASP group parameter, additional checking and fixing is done by the system jobs. All of the active jobs on the system are checked to see if the job might be in OUTQ status (job has completed), but doesn’t own any active spooled files. If so, the job will be removed from the system. In addition, jobs found on damaged job queues are also recovered and moved to the QRCL/QSPRCLJOBQ job queue.
I’d like to thank Kevin Vette for writing this blog article. Kevin is a member of print/spool team in the IBM i development lab. Thanks, Kevin!
This blog post was edited for currency on January 31, 2020.
This blog post was originally published on IBMSystemsMag.com and is reproduced here by permission of IBM Systems Media.