|
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
----- Original Message -----
From: "Charles Wilt" <charles.wilt@xxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Tuesday, May 05, 2009 3:42 PM
Subject: Performance of WRKOUTQ OUTPUT(*PRINT) vs. List Spooled Files
(QUSLSPL) vs. Open List of Spooled Files (QGYOLSPL)
All,
We've currently got a home grown app that uses WRKOUTQ OUTPUT(*PRINT)
to build a spool file of all spool files on a particular OUTQ. Then
it loads those into a DB file and displays reports matching a certain
criteria (name, date, user data) to the user for the user to view or
print.
Given that one of the output queues in question has 215,000 spool
files, our application sucks up lots of resources but does provide
currently acceptable performance.
I'm looking to redo the app to use less resources while providing the
same or better performance.
I'm wondering if anybody has any input to provide about the
suitability of List Spooled Files (QUSLSPL) vs. Open List of Spooled
Files (QGYOLSPL) to meet those requirements.
Otherwise, I'm thinking of a redesign that would probably envolve
having a data queue attached to certain output queues so that the
application could maintain it's own DB file without having to rebuild
the file each time.
Comments on that approach are welcome also.
And no, having the users actually delete some spool files is not
realistic on my part :)
Thanks,
Charles Wilt
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.