barrett@jhunix.HCF.JHU.EDU (Dan Barrett) (03/27/91)
If you have any printers hooked up via LAT, then there is something
you should know. According to Ultrix Software Support, you should NEVER
associate your very first LAT tty with a printer: it causes unpredictable
glitches.
This is undocumented.
You can find your "first" LAT tty by doing to /dev and typing:
$ file tty* |grep 39
tty02: character special (39/0) LAT #0 terminal #0
tty03: character special (39/1) LAT #0 terminal #1
tty04: character special (39/2) LAT #0 terminal #2
tty05: character special (39/3) LAT #0 terminal #3
tty06: character special (39/4) LAT #0 terminal #4
...
In the above example, tty02 is the first LAT tty (LAT #0, terminal #0).
So, you should never dedicate /dev/tty02 for a LAT printer -- always
for a normal terminal.
Put a note in /etc/ttys next to this tty entry, saying that
it should always be used for a terminal and never a printer.
I don't know anything more about the reason. In fact, when I
asked the Software Support engineer, he said they had discovered this
glitch "by experience".
Dan
//////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
| Dan Barrett, Department of Computer Science Johns Hopkins University |
| INTERNET: barrett@cs.jhu.edu | |
| COMPUSERVE: >internet:barrett@cs.jhu.edu | UUCP: barrett@jhunix.UUCP |
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////lr@cs.brown.edu (Luigi Rizzo) (03/27/91)
In article <7832@jhunix.HCF.JHU.EDU> barrett@jhunix.HCF.JHU.EDU (Dan Barrett) writes: > > If you have any printers hooked up via LAT, then there is something >you should know. According to Ultrix Software Support, you should NEVER >associate your very first LAT tty with a printer: it causes unpredictable >glitches. > ... details omitted This reminds me something... when we installed Ultrix 4.0 on a microVAX3500, we experienced a strange behaviour on the LAT printer: after printing some lines, the printer stopped for a while, and lpq said "sleeping for 60 seconds". Then the printer started again for a while, stopped again "sleeping for 120 seconds", and so on, the daemon being apparently more and more tired and doubling its sleep time after each attempt. After several days of work being unable to solve the problem (the Digital support wasn't able to replicate it nor it was a known problem) I gave up and went back to Ultrix 2.2.1, which is our current release. I'm not sure of which LAT tty I used, but there are good chances that it was tty00, our first one, as I didn't use the old printcap. I think it's just by chance that our old (and current) printcap uses tty01 for the LAT printer... Did someone else experience such a problem ? Luigi ================================================================== Luigi Rizzo Brown University & Univ. di Pisa e-mail: lr@cs.brown.edu, luigi@iet.unipi.it ==================================================================
weis@netmbx.UUCP (Dietmar Weis) (03/27/91)
lr@cs.brown.edu (Luigi Rizzo) writes: >In article <7832@jhunix.HCF.JHU.EDU> barrett@jhunix.HCF.JHU.EDU >(Dan Barrett) writes: >> >> If you have any printers hooked up via LAT, then there is something >>you should know. According to Ultrix Software Support, you should NEVER >>associate your very first LAT tty with a printer: it causes unpredictable >>glitches. >> ... details omitted [...] >said "sleeping for 60 seconds". Then the printer started again for a >while, stopped again "sleeping for 120 seconds", and so on, the daemon >being apparently more and more tired and doubling its sleep time after >each attempt. After several days of work being unable to solve the >problem (the Digital support wasn't able to replicate it nor it was a >known problem) I gave up and went back to Ultrix 2.2.1, which is our >current release. > Did someone else experience such a problem ? > Luigi >================================================================== >Luigi Rizzo Brown University & Univ. di Pisa >e-mail: lr@cs.brown.edu, luigi@iet.unipi.it >================================================================== Yes, I did. It occured on a DECsys3100 with 4.0 on a friday. There wasn't anybody there, who could manage the lpr spool system (thats another story) BUT: Further printing on that port was impossible, the weekend came. Till monday there must have sth accumulated, shortly after the first logins the system CRASHED ! And became unbootable rsp. could not be brought back to multi user mode. The PANIC and other messages pointed out the spool or lat system. Booting to single user mode, cleaning the lpr system, powering off the terminal server and starting and stopping lat resolved it. The lp error log was filled with "sleeping for ... seconds" and "socket in use", the PANIC messages were sth like "print locks held by nonexisting process" and other stuff which I can't remember at the moment. I can't remember if lat port 1 was involved but I know that there IS a printer on port 1 I inspected the printcap again, called DEC and then included the ct and uv keywords and the [io]f=/usr/lib/lpdfilters/xf. The "sleeping" error has obviously gone, but the "socket in use" error still appears. It stopps printing as well. It happens when you power off the printer during printing. Then you have to log on to the server and logout the port, clean and restart the spool queues. Very annoying. Many other mysterious things happen, also with terminals. Some times they are dead, and again, the ports have to be logged out. BTW, the server is an emulex p4000 with beta release software (as mentioned in the release notes). (No problem with this server and software on a vms system.) Its very frustrating, because the customer is getting nervous and in the near future propably angry. I count on the patches I will receive next week or so. Dietmar -- ============================================================================ weis@netmbx.UUCP | Dietmar Weis DONOP CONSULT GmbH Voice: 030/884 28 54-0 | Uhlandstrasse 179/180 Fax: 030/882 55 29 | D - 1000 Berlin 12 ============================================================================ -- weis@netmbx.UUCP | Dietmar Weis DONOP CONSULT GmbH Voice: 030/884 28 54-0 | Uhlandstrasse 179/180 Fax: 030/882 55 29 | D - 1000 Berlin 12