Update1: Got it to function at 80% for SCS SPOOL Files. I was able to reprint about a dozen previously deleted SPOOL files exactly as they were original printed.

According to the IBM SPOOL File manual, QSPL database members are cleared after a SPOOL File is printed (and not saved) or it is deleted. Although I do not see that actually occurring--rather it tends to mark the SPOOL members a unused or 'cleared' and does not actually perform a CLRPFM on the member. Therefore I was able to recover over 23 SPOOL files deleted from a user's OUTQ.

There is an issue with "end of SPOOL file" however. Sometimes its fine other times it seems to have remnants from other SPOOL files or other parts of "this" SPOOL file.

My thinking on this one is that they reuse the SPOOL file members (that's a fact, not a guess) and may avoid deleting the existing records in the SPOOL database file for performance reasons. Therefore their must be a code or SPOOL file ID embedded in the record check-digits or perhaps another EOF code. Still hunting.

I would guess that RCLSPLSTG is the SPOOL equivalent of CLRPFM. It's been a while since I read up on spooled files, but they use storage progressively, when a spool file is deleted, that storage is then available for newly created spool files (before new storage is reserved). Performing a RCLSPLSTG frees up storage reserved for spool files.

Neil, right but the docs also say that the members in QSPL are cleared. The word "clear" could be a contextual misunderstanding on my part, I read it as CLEAR (as in CLRPFM) whereas they may simply set the header to X'00' or something like that. Still researching, but so far I am able to reproduce deleted SPOOL files however, some have extra content at the end--beyond the original SPOOL file.

My guess is that they do NOT actually do a CLRPFM but rather set it to X'00' in the first 16 or so bytes of the member. Then leave the records in the file. So if the new SPOOL file using "this" member is shorter than the previous SPOOL file, the extra stuff may still be in the file, but the new file knows where it ends, so its no big deal.

I just have to discover what those readers are--it was pretty easy to learn (teach myself) the SCS data stream in an hour, but the headers on each record in the QSPL members is not intuitive. Not that it needs to be.

They probably do something like set the spool length to zero. Of course you don't know what the correct length should be off the bat, but should you guess right you would not get the extra (former spooled output) stuff at the bottom. At least that's my guess.

Right... looks like that ending record contains the last parts of the SPOOL file and when it ends, the prior record's data is replicated verbatim. Its almost as if they build a space with the SPOOL data, write the new stuff to it, then save it to the database, but don't first clear the space before continuing. So, yes, I believe the first 16 bytes or so of the SPOOL file contained the spool data space length.

The cool thing is, it really does print just fine until you get whatever is in that last record to show up. Since the records are either 512 (v7r1 and later) or 4079 (pre-v7r1) you can end up with a lot of trailing crap on the report... but hey, this is an UNDELETE SPOOL FILE command nothing more, so perhaps that's good enough.