I use both *dtaqs and the APIs, depending on what I need. No weird results with the APIs except when I have more spoolfiles than they can handle. (We routinely have 100,000 or more spoolfiles in our biggest system.) So, I'm now digging into the various 'Open List' APIs to see how they can help.

---

I just wrote a program that does pretty much the same thing. It constantly monitors an outq. When a new file pops up, it moves the file to a new outq. It is a never ending C/L program that sleeps once in awhile then calls an RPG program to do the dirty work. The heart of it is in the RPG program. Using QCMDEXC it runs WRKOUTQ OUTPUT(*PRINT), then copies that spool file to a data base file. Then it deletes the WRKOUTQ spool file. The data base file now has more than enough information in it (including job number) to make decisions and run further commands against the spool files on the outq being monitored. I am running CHGSPLF but CPYSPLF will work just fine. If this meets your needs and you need further information let me know. John P.S. I tried using API's to list the spool file into a user space and read the user space but I was getting weird results. I was running out of time (and getting pissed) so I did it the old fashioned way.

---

There are two problems with the *dtaq method that irritate me. First, the *dtaq entry is sent when a spoolfile goes to *RDY status; *HOLD or any other status doesn't do it. And second, a *dtaq entry is sent *every* time a spoolfile goes to *RDY status; place the spoolfile on *HOLD, then release it and you get another *dtaq entry. That is, the *dtaq entry is not sent when a spoolfile arrives on the *outq; the entry is sent "when a spoolfile goes to *RDY status". Do you have a way around either of those issues?

---

The best way to retrieve spool file info is to use a data queue attached to the output queue. When a spool entry goes to ready in the output queue, an entry is written to the data queue with all the spool file's info. You can then receive the data queue entry and substring the field entry into info needed for CPYSPLF. The layout of the data queue entry can be found in the "IBM Printer Device Programming Guide". I have done this many times and works great.

---

This can be pretty easy assuming a couple of things: (1) The copy take place withing the same job stream (2) There is only one spool file or the one you are coping is the last one. #2 can be worked around if the statement is not true. Use the SPLNBR parameter of the CPYSPLF command. SPLNBR can be *ONLY (the only spool file for the job), or *LAST (the last spool file for the job), or the actual spool file number.

---

Yes, there are APIs to retrieve spooled file information, but maybe you'd like the use of a data queue connected with the output queue(s). You then receive an entry in the dtaq every time a spooled file gets the status READY. In the entry, you find all infos to access the spooled file, including spooled file number. This is the best performing method; you do also use a minimum of system ressources, when you wait "for ever" for a data queue entry.

---

Two possible APIs, depending on exactly how much you know at the time the function runs and exactly what you need to know. Both are in the Print APIs section of the API documentation. The first is the List Spooled Files (QUSLSPL) API and the second is Retrieve Spooled File Attributes (QUSRSPLA). The first will return a list of spooled files depending on what you ask for, e.g., all spooled files for current user, all spooled files on a particular outq, etc. And the second returns the attributes for a specific spooled file. If you know you want the *LAST splf named QSYSPRT for the current job, then all you need is the second API. Lots of combinations possible.

---

the more easy way if you can is to include CPYSPLF just after print program and use *last (or *only if it is) as number.

---