|
Hello Dave, I am sure you realise this but submitting large numbers of jobs that do very little work is an extremely good way to kill system performance regardless of the settings of QACTJOB and QTOTJOB. A NEP program is a better approach -- but then we are back to the original problem :) Other suggestions (including your second one) are a better approach. Regards, Simon Coulter. «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«» «» FlyByNight Software AS/400 Technical Specialists «» «» Eclipse the competition - run your business on an IBM AS/400. «» «» «» «» Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 «» «» Fax: +61 3 9419 0175 mailto: shc@flybynight.com.au «» «» «» «» Windoze should not be open at Warp speed. «» «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«» //--- forwarded letter ------------------------------------------------------- > Date: Thu, 04 Feb 99 15:18:22 +0000 > From: david.kahn@gbwsh.mail.abb.com > To: MIDRANGE-L@midrange.com > Reply-To: MIDRANGE-L@midrange.com > Subject: RE: Max spool entries 10,000 per JOB?? > > "Allen, Mark" <ALLENMA1@Mattel.com> wrote: > > >When the program that > >relieves component inventory runs it produces a report showing what was > >relieved. This report goes to an outq that is not attached to a printer. > >This outq is cleared weekly. The only time the report is looked at is if > >there is a perceived inventory relief problem. So for each finished good > >item produced there is a spool file. > > Mark, > > So the program is invoked thousands of times within the same job? 2 > potential workarounds spring to mind. > > 1. Instead of calling the print program, submit it to a dedicated job > queue. Each report is now in a separate job. The downside is a large number > of jobs in the system: for optimum performance you may need to adjust the > tuning (eg. system value QTOTJOB). > > or > > 2. Override the printer file with SHARE(*YES) MAXRCDS(*NOMAX) and call a > program to pre-open it. Then each invocation of the program should be able > to share the spooled file's open data path. Now you have tens of thousands > of pages but only one spooled file. Downside: a large spooled file to > manage and tricky to print a single selected page, especially if the file > is still open. On the other hand, it's easier to scan 1 large spooled file > for a string than 9999 little ones. Maybe you could compromise and close > and re-open the file after every hundred or so invocations of the print > program, giving you a hundred times the capacity of your current solution. > > I hope these ideas are useful. You may not go with either of them, but at > least they give you options to consider, and they may prompt you or someone > else on the list to think of something better. > > Regards, > > Dave Kahn, ABB Steward Ltd. +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
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.