mark@ece-csc.UUCP (Mark Lanzo) (12/04/86)
This is essentially a reposting of an earlier question to which I got
no real answers, so I try again...
I've been having problems with printers hooked onto microvaxes, and wondered
if someone out there could provide a solution.
Specifically, I've got a uVax II running Ultrix 1.2. We have an LN03 printer
hooked to one of our tty ports. When printing long files (or lots of short
ones), things seem to break sometimes -- the printer loses some text, often
part of the last page of a file (but not always). Sometimes, the LN03
signals some sort of error (unfortunately, I can't remember the exact
error, and I can't duplicate the error when I want to!). Someone else I
know has a Vax workstation with an LA50 connected on the console port.
It exhibits similar problems, although instead of flashing an error indicator,
the LA50 usually prints out some garbage (often backwards question-marks),
and then freezes up completely.
I originally thought that the problem lie in the system not
recognizing ^S/^Q from the printer, but I have hooked a terminal
on that line and tried ^S/^Q while 'lpr'ing to the terminal, and THAT
worked okay.
I've tried twiddling the /etc/printcap entry in all sorts of ways, with no
real success. DEC has not been able to provide an answer (or more precisely,
they provided a *wrong* answer).
I've been hearing the same complaint from the managers of several other uVaxen
in the area -- and also from other users over the net who requested the
answers I got from my last posting -- so I know this is not too uncommon.
The system configuration is not always the same -- other printers
(usually LA50), or they have a Vax workstation (I *think* in this case the
printer is connected to the console port, and I don't know how that may differ
from the regular tty ports). At any rate, the problem appears to be either
in "lpr" or the communications between the printer and the vax, since the
symptoms are similar in each case.
Our current printcap entry basically looks like:
lp|LN03:\
fs#0321:fc#0456:\
xs#040000:xc#037777:\
br#4800:lp=/dev/tty00:
Any help you can offer would be greatly appreciated.
(... end of original posting ...)
So far, I've only gotten two replies, other than requests for summaries.
My apologies for not replying to those people who have sent mail to me.
Our "mail" system is not working 100% at the moment, and most of the
things I reply to bounce back with an "unknown host" message.
(Yes Sanand, I tried!)
I will include those replies here, since it seems to be the only way
to let the other people wanting summaries to know what is going on.
=
= From harvard!necntc!necntc.NEC.COM!jeff@seismo.uucp Thu Nov 20 22:27:15 1986
= From: harvard!necntc.NEC.COM!jeff@seismo.uucp (Jeff Janock)
= Hi -
=
= We run an LN03 off of our 780 running 1.2 Ultrix.
= Try this entry....
=
= % cat /etc/printcap
=
= ln|a local LN03 printer:\
= :lp=/dev/ttyjf:\
= :sd=/usr/spool/lnd:\
= :dn=/usr/lib/lpd:\
= :lf=/usr/adm/lnerrs:\
= :if=/usr/lib/ln03of:\
= :of=/usr/lib/ln03of:\
= :af=/usr/adm/lnacct:\
= :rw:\
= :br#9600:\
= :fc#0177777:\
= :fs#023:\
= :mc#20:\
= :pl#66:\
= :pw#80:
=
= --
=
= Jeff Janock
= NEC Electronics Inc.
= One Natick Executive Park
= Natick, Massachusetts 01760
= +1 617 655 8833
=
= ARPA: jeff%necntc.UUCP@harvisr.harvard.edu
= within UUCP domain: jeff@necntc.NEC.COM
= should work: jeff@necntc.UUCP
=
= or if need be:
= {decvax | pyramid | husc6 | mirror}!necntc!jeff
= gatech!gt-eedsp!necntc!jeff
Jeff -- could you tell me what /usr/lib/ln03of does precisely? (I know it's
a filter, but I have no documentation about any of the available filters --
I know that when we first installed 1.2 Ultrix on this system there was a
/usr/lib/lpf or something like that in the /etc/printcap entry which screwed
things up since it filtered out control codes).
Incidentally, I should emphasize that this problem isn't specific to the LN03.
My second reply:
= From kevin@ncspm Fri Nov 21 18:24:19 1986
= From: Kevin D. Bond <kevin@ncspm>
=
= Mark,
=
= I think I can help with your printer problem (no promises :-) ),
= actually all I can do is point out the problem, and a possible work-around.
=
= Enough of this garbage, I had a similar problem on our NCR tower
= running System Vr2.0, the problem is not in the printer or the interface
= to the uVax, but in the software. The problem is that if the driver
= software does any changes to the port (i.e. baud, parity, etc...) and
= then does not wait for the output buffer to flush before resetting the
= terminal, or you run a getty on this line that resets it, then the last
= buffer-full of output will be sent out at the wrong settings, depending
= on the firmware in the printer it will does something weird with this
= ours (HP Laserjet+) gives a buffer overflow error. The fix to this is
= to make sure that whatever driver you are using waits for the last buffer
= to flush, and then goes on and resets the terminal line.
=
= This is basically the problem I encountered, on System V there is
= a ioctl call TCSBRK, which will wait for output to complete. I believe
= that the SysV emulation under Ultrix supports this, but since it is a
= 4.2 BSD kernel, I would guess that it does not work as advertised, but
= worth a try.
=
= Good Luck, and if you would; drop me a line and tell me what you find,
= as I like to keep up on these kinds of things so that when I see them
= again I can fix them.
=
= ------------------------------------------------------------------------
= Kevin D. Bond uucp: ...!mcnc!ncsuvx!ncspm!kevin
= 4403 Williams Hall internet: ncsuvx!ncspm!kevin@mcnc.mcnc.org
= NC State University
= Raleigh, NC 27650 tel: (919)-737-2594
=
=
I don't think this applies in our case, but it may help cure some problems
other people are having.
We don't have anything running which should alter the terminal settings (such
as "getty") -- AS FAR AS I KNOW. The line is dedicated to the printer.
However, I must admit that the symptoms would be well explained by this sort
of problem -- except for the fact that files do break in the middle sometimes.
The backwards question marks and other garbage put out by the LA50 definitely
sounds like the baud rate changing in the middle of things (but why?).
We don't have a source license, so we couldn't fix the driver if we had to.
If ANYBODY out there can help me to write a Ultrix 1.2 device driver,
I *really* want to hear from you!!!
But yes, I definitely do suspect software rather than hardware.
At any rate, thanks for the replies!
Mark Lanzo
...decvax!mcnc!ece-csc!markgrr@cbmvax.UUCP (12/10/86)
In article <3136@ece-csc.UUCP> mark@ece-csc.UUCP (Mark Lanzo) writes: > >I've been having problems with printers hooked onto microvaxes, and wondered >if someone out there could provide a solution. > >Specifically, I've got a uVax II running Ultrix 1.2. We have an LN03 printer >hooked to one of our tty ports. When printing long files (or lots of short >ones), things seem to break sometimes -- the printer loses some text, often >part of the last page of a file (but not always). Sometimes, the LN03 >signals some sort of error (unfortunately, I can't remember the exact >error, and I can't duplicate the error when I want to!). >I originally thought that the problem lie in the system not >recognizing ^S/^Q from the printer, but I have hooked a terminal >on that line and tried ^S/^Q while 'lpr'ing to the terminal, and THAT >worked okay. Well, here is what we're using, on a 750. The fc/fs settings are derived from somthing we got from DEC. You can work them out from the sys/ioctl.h header file or something like that. Of course those definitions are in HEX, while the printcap file is in OCTAL. ln|lp|ln03|ln03 laser printer:\ :lp=/dev/tty09:sd=/usr/spool/lnd:\ :dn=/usr/lib/lpd:rw:br#19200:fc#0177777777777:fs#010000003:\ :pl#66:mc#20:\ :of=/usr/local/lib/lpdfilters/ln03of:\ :if=/usr/local/lib/lpdfilters/ln03of:\ :tf=/bin/cat:\ :lf=/dev/console: It really sounds like you have some kind of control-q/control-s problem, normally hidden by the big buffer in the ln03. Perhaps you have the ln03 set up to transmit parity and the spooler sitting there in the wrong mode. The dope DEC gave use had the fs# ending in 23, which turns on lf->cr/lf translation. For some reason or other we were trying to shove binary data at the printer, so I turned this off, and wrote an output filter that would do this translation, unless you specified binary transfer. In general, the filters are neither needed nor desirable - the general notion is documented in The Line Printer Spooler section in the Ultrix Supplementary Documentation - Volume II. Unfortunatly, they don't reveal one of the ugliest kludges known to mankind that is stuck in the spooler/ filter interface. -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)