need URGENT help with SCO UNIX / TCP/IP - please

[Johnny Schweigl]

We are currently encountering a major problem with no idea how to solve it.
Machine configuration is as follows:

Hardware:
	COMPAQ Systempro
	two 386/33 CPU boards
	12 MB mem
	1.6 GB Disk, configured for data guarding
	3COM Etherlink II network adapter
	Adaptec SCSI controller 
	GIGATAPE DAT streamer
	SCO UNIPATH SDLC comms board
	Computone controller with 1 Async feature box attached

Software:
	SCO UNIX 3.2 Runtime
	TCP/IP 1.1.1 Runtime
	SCO (Corollary) MPX
	COMPAQ EISA supplement

Operating environment:
	Machine serves as time accounting system with industrial terminals
	connected via RS232. Users (>25) telnet from WANG VS (great, BTW)
	to SCO box, using accounting software.
	32 pty's are configured into the kernel (maximum allowed by TCP/IP).
	C2 security mode is relaxed (from sysadmsh).

Error:
	After entering userid and passwd (telnet session is ok) SCO UNIX
	responds with "Cannot obtain database information on this terminal".
	when logging on as root on /dev/console, the system tells me that
	"The security databases are corrupt". No new logins are allowed after
	this error had occured.
	The error seems to have no systematic behaviour. It appears at random
	points in time, with 3 telnet sessions or 20, or something like that.

RTFM: 
	SCO TCP/IP release notes predict this error if pty's and vty's are not
	correctly configured. Nope. As far as I can see I did it right. Simply
	followed the instructions in the manual.
	No further reference to this error in the complete runtime docs.
	Also, the TCP/IP manual says, that if streams ressources are insufficient,
	unpredictable errors.

Possible sources of error:
	Someone modified /etc/passwd manually. System will be reinstalled
	completely this weekend. If this was the only problem, shouldn't the
	error occur permanently? Quite contrary, it is not reproducible.

Actions taken so far:
	Analyzed streams ressource usage with crash and strstat subcommand,
	reconfigured kernel. Should now be sufficient.
	Ran a brute force test with 32 concurrent telnets and some parallel 
	ftp's. Error did not occur. Next day, error occured 8 times. One day
	later 3 times, and so on ...

Problem:
	Angry users wanting to tear our heads off.
	So if you know any solution, or if this is a known error, corrected in
	release x.y.z pleeeaaase tell me.

Thanks in advance, 
	
	
 

-- 
This does not reflect the   | Johnny Schweigl
opinions of my employer.    | USENET: schweigl at edvvie.at
I am busy enough by talking | 
about my own ...            | EDVG  Vienna/Europe, Tel (+43 222) 59907-0