Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!WAIKATO.AC.NZ!lindsay
From: lindsay@WAIKATO.AC.NZ
Newsgroups: comp.laser-printers
Subject: Re: QMS 410 Laser Printer
Message-ID: <9103221850.AA11876@crayola.cs.UMD.EDU>
Date: 22 Mar 91 10:22:00 GMT
References: <9103132036.AA25566@crayola.cs.UMD.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: University of Waikato, Hamilton, New Zealand
Lines: 32
Approved: laser-lovers@brillig.umd.edu

In article <9103132036.AA25566@crayola.cs.UMD.EDU>, 3IU4TOB@CMUVM.BITNET writes:
> I am interested in hearing about anyone's experience with the QMS 410 printer,
> in particular in a mixed PC and Mac environment.
> 

We have a large number of these printers in a PC / Vax /Mac environment, the
Macs and PC's being supported via Pathworks. We evaluated these printers
against a range of other postscript printers and they compare very favourably
with other offerrings. In particluar, their processing speed is comparable with 
a number of 8 ppm postscript lasers we have. In our particular environment the
printers are locked in postscript and we have a print symbiont that handles
text to ps conversion.

Now for the downside. We have encountered 2 major bugs in the printer firmware.
The first was a simple programming error which resulted in a printer response
message not being formatted according to the postscript bible. In version 1 at
least of the firmware this was correct, but by version 5 it was a problem. This
will probably only cause a problem if tyou are interpreting repsonses from the
printer (as you need to do in a Vax environment). Version 7 of the
firmwarecorrects this problem.
The second bug, has just in fact been found today and is a serious one. The
printer gradually consumes available memory until it runs out completely and
crashes. This takes a variable amount of time and appears to be related to the
complexity of documents printed. It is easy to track, just  print a status page
ocassionally and see it disappear. On a busy VMS queue, it takes only about a
day!!. When it does crash it trashes all your settings such as baud rate etc.
No valid postscript command to reset the printer or cause it to carry out
garbage collection is effective. One wonders how such a fundamental bug can get
through product testing.
Before looking further at this printer I would suggest you ensure that this
particular problem is fixed. At this time QMS can not give us a fix for the
problem.