× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



We have several hundred laser printers attached. I don't know the
percentage that are set us as remote output queues. Most of the time,
very low print volume. Does the number of output queues effect
performance even when no data is being sent to be printed?

Also, I heard a comment attributed to a third party. The comment, as
best as I heard it and can remember, (noisy room), was that it could
take 90 seconds for a queue to get rescanned for output to print, and
performance depended on when new output arrived in the queue. That
sounds odd, somehow. I have no idea where the 90 seconds came from.
As to CPU load, this box has never appeared slow. The few times I
have looked, percent CPU has never been even over 30.

Makes me wonder if spooling subsystem priority is also a factor. But,
I am loathe to mess with settings and get the sa who resides in his
own world, "offended". As far as I can tell, this issue should really
be his to deal with. But, nobody wants to get involved with him.
Where can I get a job where nobody ever asks me to do anything and I
don't get fired for doing almost nothing? Very sad situation.

John McKee

On Tue, Dec 27, 2011 at 3:45 PM, DrFranken <midrange@xxxxxxxxxxxx> wrote:
I suspect very little. If each is using host print transform they both
need to do that work and the rest is communications.

First thing I would take a look at is the size of the memory pool used
for spooling/printing.  Bring up WRKSYSSTS and use F21 to set to 2 or
3(Intermediate or Advanced).  Use F10 to reset statistics then have
someone crank up a print job that is tagged as 'slow'.  Using F5 (Not
F10) refresh the screen and watch the Fault columns for the *SPOOL
pool.   I have seen those numbers go to 4 digits then I see the spool
pool is at a measly 4 or 8M....... and that's the problem. If that's the
case the pool needs to hold a bit more memory when it's not being used
so that when work comes along it has space to work.

To fix it use WRKSHRPOOL and adjust the 'Minimum Size %' column for the
*SPOOL pool. (You'll need to press F11 to see it)  The default is 1
meaning it can shrink to 1% of the total memory on the system. For a 4G
machine that's 40M but if you have a 1G machine it's only 10 which isn't
likely enough.  Available memory is displayed at the top of that page.
Using that, figure out the percentage needed to set the 'floor' at about
32M to start. Then test again to see if performance improves. If not
perhaps 48M is a good next step.

Of course if the machine is pounding along at 100% CPU this might not
help as much so standard warning about YMMV!

I have seen this small change turn 2 minutes into 10 seconds for a print
job, hopefully it helps you as much!

    - Larry "DrFranken" Bolhuis

On 12/27/2011 10:28 AM, jmmckee flinthills.com wrote:
Is there any performance difference between using remote outq and a
*DEVD for printing?  There are complaints where I work of output
taking "too long" to be produced from the i.  Another system that
sends postscript data seems to print faster.  Printers are Lexmark
Optra.

Thanks

John McKee
--
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 thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.