Re: Performance of WRKOUTQ OUTPUT(*PRINT) vs. List Spooled Files (QUSLSPL) vs. Open List of Spooled Files (QGYOLSPL)

Charles, note that the list processing APIs use caching extensively. I don't know the technical details of how the caching works, but in practice, this means that the first time you call the API you will see a delay, and then subsequent calls will be much faster. As an example, listing all the members in a library can take upwards of 60 seconds the first time and then a few seconds the next.

What this means practically speaking is that you might want to include a priming call in your IPL procedure. That would only work, though, if one person's call actually makes another person's subsequent call faster (that is, the caching works across jobs) and unfortunately I haven't taken the time to test that.

Joe

Thanks Bruce and Rick....I was leaning that direction.

Charles

On Tue, May 5, 2009 at 8:49 PM, bvining <bvining@xxxxxxxxxxxxxxx> wrote:

Open List of Spooled Files is the way I would go. You won't run into space
limitations, you can get a degree of parallelism with your database writes
and the APIs background processing, ...

I'm not sure how attaching a *DTAQ to selected *OUTQs will allow you to
maintain your own database (without rebuild). While *DTAQ messages can be
received for some transitions related to spooled files, I don't believe you
will be able to track all changes to the spooled files.

Bruce