Undocumented LAT printer "feature" -- save for your records!!

[Dietmar Weis]

lr at cs.brown.edu (Luigi Rizzo) writes:

>In article <7832 at jhunix.HCF.JHU.EDU> barrett at 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 at cs.brown.edu, luigi at 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 at 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 at 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