Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!unmvax!uokmax!munnari.oz.au!metro!dbsm!maf
From: maf@dbsm.oz.au (Martin Foord)
Newsgroups: comp.unix.admin
Subject: Printing and bitbuckets
Message-ID: <1991Feb20.032249.29595@dbsm.oz.au>
Date: 20 Feb 91 03:22:49 GMT
Reply-To: maf@dbsm.oz.au (Martin Foord)
Organization: Dominguez Barry Samuel Montagu
Lines: 26


        We have a SUN 4/490 and two annex boxes on the same network. Each annex
box has two printers off serial lines. All these four printers are used heavily
during the course of each day. The mechanism by which one prints from the annex
is by using a command "aprint", which makes a connection to the specified annex
and port (the port and line both being supplied by command arguments). So,  the
printcap  file has an lp=/dev/null, and the if=/usr/local/lib/annexcat which is
a script to pipe the data to "aprint". A problem occurs  when  people  try  and
print on more than one printer, and therefore all printers try to get access to
/dev/null, and so the first come gets first served. Therefore,  if  someone  is
printing  a  *huge*  job  on one printer off the annex then and some other user
trys to print on another printer, the new user must wait for the  huge  job  to
finish  (ie: until they free the lock on /dev/null). My question is: What sorts
of solutions have system administrators come with to this problem ? Has  anyone
ever  had this problem ? Having multiple bit buckets (how is this done?) ? I've
tryed setting an lp as a different /tmp file for each printer, and then  remove
that  file after the print job has finished - but this doesn't seem to work ...
("no daemon present").

Any enlightening suggestions ...

							Martin.
-- 
Martin Foord.				MHSnet/ACSnet:  maf@dbsm.oz.au
Dominguez Barry Samuel Montagu.		Internet Gateway:
Phone: +61-2-258-2724			maf%dbsm.oz.au@munnari.oz.au