Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ames!ucbcad!ucbvax!phri.UUCP!roy
From: roy@phri.UUCP (Roy Smith)
Newsgroups: comp.laser-printers
Subject: Re: printer queues
Message-ID: <8707311652.AA22756@brillig.umd.edu>
Date: Thu, 30-Jul-87 21:04:17 EDT
Article-I.D.: brillig.8707311652.AA22756
Posted: Thu Jul 30 21:04:17 1987
Date-Received: Sun, 2-Aug-87 01:01:13 EDT
References: <8707301846.AA02745@brillig.umd.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: cmcl2!phri!roy@seismo.CSS.GOV (Roy Smith)
Distribution: world
Organization: Public Health Research Inst. (NY, NY)
Lines: 26
Approved: laser-lovers@brillig.umd.edu


In <8707301846.AA02745@brillig.umd.edu> curt%cieunix@CSV.RPI.EDU (Curt Signorino) writes:
> When we send something to either the decwriter or the laser printer and
> then do an lpq, both queues appear to have the file even though it was
> only sent to one of them.

	Most likely, the two printers share the same spool directory.  This
is not necessarily bad, but will confuse lpq.

> Also, if a job is interrupted on the decwriter or the laser printer,
> it finishes printing out on the other.

	We've never seen this behavior, but we only share spool queues for
remote printers, i.e. on every machine, each local printer has its own
/usr/spool/printername directory, but all the remote printers share a
common spool directory: /usr/spool/lpd.  Since lpd jobs only exist there
for a very short amount of time (while being sent to the remote machine),
it's very likely that we've never lprm'd a job while it was there.

	I'm not sure why we chose this arrangement, and I keep thinking
that I probably should change it, but I'm a firm believer of "if it ain't
broke, don't fix it".
-- 
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016