RE: Max spool entries 10,000 per JOB??

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
+---