How many printers are supported?
Clifford
to the devices because the admin says that the spooler can't handle 75
printers. We're running SCO open server?
Is it wise to bypass the spooler and have the applications write directly to
the devices?
Is Unix robust enough to handle this many printers? Is there a limit to the
number of print devices in unix?
Thanks.
Clifford
Jean-Pierre Radley
ONE posting suffices, what's this barrage? Trying to test how many
of your messages are supported???? Sheesh!
I see no inherent limit to how may printers can be supported. What
evidence does the administrator adduce?
--
JP
Clifford
Well, he says that the lpstat command takes too long - maybe 10 seconds to
produce a list of jobs.
He wants us to put a software lock in the application indicating that a
print job is occuring rather than letting the spooler handle the task. I
think this is bad advise. Afterall, that's what the spooler is for. There
is no delay in any of the print jobs.
"Jean-Pierre Radley" <j...@jpr.com> wrote in message
news:2001031119...@jpradley.jpr.com...
Jean-Pierre Radley
| "Jean-Pierre Radley" <j...@jpr.com> wrote in message
| news:2001031119...@jpradley.jpr.com...
|
| > Clifford propounded (on Sun, Mar 11, 2001 at 07:15:18PM -0500):
| >
| > | We're having a debate about whether to bypass the spooler and
| > | write directly to the devices because the admin says that the
| > | spooler can't handle 75 printers. We're running SCO open server?
| > |
| > | Is it wise to bypass the spooler and have the applications write
| > | directly to the devices?
| > |
| > | Is Unix robust enough to handle this many printers? Is there a
| > | limit to the number of print devices in unix?
| >
| >
| > ONE posting suffices, what's this barrage? Trying to test how many
| > of your messages are supported???? Sheesh!
Top-posting upsets me. :-)
| Sheesh is right!
So ? Why the barrage?
| > I see no inherent limit to how may printers can be supported. What
| > evidence does the administrator adduce?
|
| Well, he says that the lpstat command takes too long - maybe 10
| seconds to produce a list of jobs.
So what? If he put in his dumb scheme, the lpstat command would return
instantly and tell him nothing useful at all.
| He wants us to put a software lock in the application indicating that
| a print job is occuring rather than letting the spooler handle the
| task. I think this is bad advise. Afterall, that's what the spooler
| is for. There is no delay in any of the print jobs.
You're right. His notion would be a useless reinvention of a wheel.
BTW, why are you playing John Alden -- why can't he come here and plead
his own case?
--
JP
Bill Vermillion
>Well, he says that the lpstat command takes too long - maybe 10
>seconds to produce a list of jobs.
Why does the running of lpstat figure into having the printers
print directly? Maybe he just needs a self-written program to
replace lpstat?
--
Bill Vermillion - bv @ wjv . com
Jeff Liebermann
wrote:
>We're having a debate about whether to bypass the spooler and write directly
>to the devices because the admin says that the spooler can't handle 75
>printers. We're running SCO open server?
Run:
customquery listpaches | head -1
for the exact version and updates.
OSR5 3.2v5.0.0 would barf at 16 configured printers. All version of OSR5
take somewhat less than forever to time out from a non-available LPD
configured printer when displaying lpstat results. If you happen to be
using 3.2v5.0.6, see:
http://osr5doc.sco.com:457/OSr506/latenews.html
for any printing related issues that might affect your arrangment.
>Is it wise to bypass the spooler and have the applications write directly to
>the devices?
No, but I do it often for serial port cash register printers. The 1-2
second delay for the print spooler to start printing is fatal on a high
traffic cash register. Printing directly to a serial port (or IP socket)
starts much faster than going through the spooler.
>Is Unix robust enough to handle this many printers?
Yes.
>Is there a limit to the
>number of print devices in unix?
I don't think so. I are not a programmist and do not have access to the
source code.
You may want to disclose:
- If these 75 printers are attached to 75 assorted serial ports.
- Whether said serial ports are directly attached to the OSR5 server
or are located on remote terminal/print servers.
- If there are any network print servers involved.
If there are network print servers, and your admin want to shovel print
jobs directly to the print servers, I suggest "netcat". See:
http://www.cruzio.com/~jeffl/sco/lp/
http://www.tkrh.demon.co.uk/netcat.html
http://www.pcunix.com/SCOFAQ/scotec7.html#getnetcat
Email from a VLC (very large company) indicated that they were
successfully using netcat for printing to something like 170 print
servers from about 15 OSR5 and Linux servers. I've had other comments
about large systems, but I don't recall the numbers. Note that netcat
simply re-directs the output to an IP socket, but uses the stock SCO
print spooler. Since lpstat is only run for locally configured printers,
it runs fast. It's the HPNP and LPD printers that slow down lpstat and
rlpstat.
--
Jeff Liebermann je...@comix.santa-cruz.ca.us
150 Felker St #D Santa Cruz CA 95060
831-421-6491 pager 831-429-1240 fax
http://www.cruzio.com/~jeffl/sco/ SCO stuff
Bill Vermillion
information.
In article <tao80j4...@corp.supernews.com>,
Clifford <clif...@speakeasy.org> wrote:
>Well, he says that the lpstat command takes too long - maybe 10
>seconds to produce a list of jobs.
>He wants us to put a software lock in the application indicating
>that a print job is occuring rather than letting the spooler handle
>the task. I think this is bad advise. Afterall, that's what the
>spooler is for. There is no delay in any of the print jobs.
The lpstat taking too long really has nothing to do with the
spooled/spooler printer functions.
In this spirit that nothing posted to Usenet every goes away -
here is an edited post from a 'je...@oriontel.com.'. It's about
a two year old post now. [I had mailed it to mysefl that's why the
quoting is a bit weird]. The 'learn by destroying' is Lieberman's
mark so I suspect this is just one of his from another site a long
time ago.
---------
From - Thu Jul 01 17:23:54 1999
To: je...@oriontel.com
Subject: Re: Disappearing Printers
Newsgroups: comp.unix.sco.misc
In-Reply-To: <3643C220...@oriontel.com>
References: <3643853F...@oriontel.com> <36438...@athena.netset.com>
Organization: W.J.Vermillion - Orlando / Winter Park
Cc:
Bcc:
In article <3643C220...@oriontel.com> you write:
>Mark L. Wise wrote:
>> I may be wrong here but... doesn't the documentation say that
>> when you install lpd that lpstat only shows the lpd printers????
>You mean I have to read the docs? Well ok, but just this time.
>A quick keyword search through the only man pages showed nothing.
>Same with scohelp. I also looked at the release notes. Nuttin.
>If it does say that, it's covering up for an lpstat bug.
>Upon further tinkering, thrashing, swearing and learn by
>destroying, I discovered how lpstat really works. It does
>a linear search through the various directories under:
> /usr/spool/lp/admins/lp/printers/*
>and reads the various configuration files. There are two
>flavours of lpstat buried under /usr/lpd/remote/lpstat and
>/usr/lpd/local/lpstat. One or both are busted.
>What gave me the clue is that the printers listed in lpstat
>seemed to follow no logical failure mode. After a few fruitless
>custom plus remove and reinstall rituals, I noticed that the
>order in which I added the printers made a big difference in
>how it fails. Since I suspected the directory order, I created
>an lpr printer named "aaaaaa" which luckily appeared at the tope
>of the directly listing and NOTHING showed on the lpstat -t
>listing. Renaming the printer to "zzzzz" didn't help because
>it still appeared in the same place on the directly listing.
>The basic cause of this nonsense is that lpstat literally quits
>as soon as it finds something either missing or indigestible.
>If the offending printer is first, lpstat -t shows nothing.
>If it's last, lpstat -t shows everything exept the lpr printer.
>In all cases, lpstat fails to announce its displeasure.
>I played with exit status and it's always 0.
>
>I never did figure out exactly what lpstat is looking for.
>I just threw in what is found in the other directories and
>left it alone. The whole thing can probably be fixed by
>fixing the /etc/rlpconf script which creates the necessary
>files and entries. Maybe if I'm ambitious, one could also
>add a way to remove lpr printers.
So now you see why the consultant who wan't to replace spooled
printers with devices, solely because he bases performance on
lptstat, is probably looking at the wrong thing.
Bill
--
Bill Vermillion bv @ wjv.com