Xref: utzoo comp.sys.ibm.pc:23014 comp.text:3037
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!killer!ames!nrl-cmf!ukma!gatech!ncsuvx!mcnc!duke!romeo!gm
From: gm@romeo.cs.duke.edu (Greg McGary)
Newsgroups: comp.sys.ibm.pc,comp.text
Subject: HP LJ-II printjob bombs from DOS after paper-out or paper-jam
Message-ID: <13017@duke.cs.duke.edu>
Date: 10 Jan 89 13:09:16 GMT
Sender: news@duke.cs.duke.edu
Lines: 32

I am using an HP LJ-II connected via a parallel port to a PC-AT clone
(Hyundai 286c) for printing TeX using Beebe's DVIJEP driver.  I have
nothing but praise for the print quality and speed, but I have a major
gripe with the PC/printer's behavior in the face of (infrequent)
paper-jams and out-of-paper conditions: if new paper isn't added, or
the jam cleared within about 20 seconds, the job aborts in the middle!
I'm used to working with Apple LW & Imagens on big UNIX boxes that
place a job in suspended animation indefinitely until such problems are
cleared, then resume where they had left off.

I normally use the MKS-toolkit cp(1) command like so:

	cp <jobname>.jep /dev/lpt1

I've tried DOS's print spooler with no luck, and find that

	cat <jobname>.jep >/dev/lpt1

opens one or both of the files in ascii-mode so that the top-bit
is stripped. (Boo!)

When cp(1) bombs after paper-out or paper-jam, I get a message on my 
console indicating that DOS knows what's going on with the printer.
It will say something like: `write failed: no paper' which leads me
to believe that a command written specifically for printing could be
smart enough to retry writes that fail on `repairable' conditions.

Any ideas?  Thanks!
-- Greg McGary	
-- 4201 University Drive #102, Durham, NC 27707   (919) 490-6037
-- {decvax,hplabs,seismo,mcnc}!duke!gm
--				    gm@cs.duke.edu