Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 UW 5/3/83; site uw-beaver
Path: utzoo!watmath!clyde!burl!ulysses!cbosgd!ihnp4!drutx!houxe!hogpc!houti!ariel!vax135!cornell!uw-beaver!laser-lovers
From: laser-lovers@uw-beaver.UUCP
Newsgroups: fa.laser-lovers
Subject: Re: Controlling a QMS
Message-ID: <1342@uw-beaver>
Date: Fri, 27-Jul-84 16:25:03 EDT
Article-I.D.: uw-beave.1342
Posted: Fri Jul 27 16:25:03 1984
Date-Received: Sat, 28-Jul-84 09:42:40 EDT
Sender: daemon@uw-beave
Organization: U of Washington Computer Science
Lines: 21

From: Bob Brown <rlb@RIACS.ARPA>
The business with the QMS is messier than all that.  We have two
programs that use the state file - qcat and a ditroff driver.  No
matter how careful we are about managing the state file and the
printer, we still get occasional fubarlike output.  Our procedure to
clean up after errors is to (a) stop the queue, (b) kill the filter,
(c) power down and up the printer (using the trick so that it skips the
multiminute L1 wait), and (d) run reset-laser-printer which contains
	/usr/local/lib/qcat -p >/dev/laser
	/usr/local/lib/qcat -s >/dev/laser
This usually does the trick, but since we use the 4.2BSD spooler,
killing the filter or daemon isn't always so easy.

QMS has told us that status queries will exist in a future release of
their QUIC system, but if you use a parallel line, there's no return
path.

Bob Brown
RIACS/NASA Ames

----------