I did not like the first solution I found–the Get Spooled File (QSPGETSP) API. QSPGETSP is plenty capable of reading an AFPDS spooled file, but the complexity of this API rivals the instructions that accompany the U.S. federal income tax return. None of that for me.
Then I discovered something interesting. One would think–or at least I thought–that the type of spooled file produced–SCS, IPDS, or AFPDS–is determined when the printer file object is created. Well, I was wrong. I found that the type of spooled file is determined at runtime.
The solution is to change or override the DEVTYPE attribute of a printer file so that it produces an SCS spooled file instead of an AFPDS spooled file. (I assume the same can be said of IPDS spooled files, but I was not able to test it to be sure.)
CHGPRTF FILE(SomePrtf) DEVTYPE(*SCS)
OVRPRTF FILE(SomePrtf) DEVTYPE(*SCS)
CPYSPLF will happily copy the text portion of the report to a disk file, which you can read and massage any way you like with a program written in your high-level language of choice.
This is correct and I appreciate your input, the only thing is I was hoping to be able to copy existing spool files created with type=AFPDS. I am going to look into the API you mention Get Spooled File (QSPGETSP) and see if I could make something out it, I will let you know how that will go.
You can’t meaningfully put AFPDS spooled files into flat physical files with CPYSPLF. There is no point to it since you couldn’t do anything with the physical file once it was created. Obviously there is a stream of bytes associated with any spooled file, but processing those bytes as AFPDS requires significant programming effort.
The Get Spooled File Data (QSPGETSP) API is far simpler than the programming that would be needed to handle flat physical files with AFPDS data.
You can go to Windows and open a .JPG file with Notepad. The result is similar to what you have in a physical file copy of AFPDS data. It simply isn’t appropriate.