Xref: utzoo comp.bugs.misc:273 comp.unix.xenix:9103
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!pallas!kabra437
From: kabra437@pallas.UUCP (Ken Abrams)
Newsgroups: comp.bugs.misc,comp.unix.xenix
Subject: Re: terminal lockup on XENIX
Keywords: ANVIL Stallion
Message-ID: <245@pallas.UUCP>
Date: 20 Dec 89 02:57:30 GMT
References: <472@iceman.jcu.oz>
Reply-To: kabra437@pallas.UUCP (Ken Abrams)
Organization: Athenanet, Inc.,  Springfield, Illinois
Lines: 42

In article <472@iceman.jcu.oz> cckba@iceman.jcu.oz (Kent Adams) writes:
>
>Problem: Terminals lockup when running with 8MB RAM but not
>	 with  4MB RAM.

Don't know what the difference in the amount of core memory has to do with
the situation but your problem closely parallels a problem I have been
having with my Xenix set up.  My hardware is entirely different 
(AT&T 6386 w/4 meg and a CTC ports board) so I doubt that it is 
really hardware dependent.  My terminals were locking up at various
random intervals and at times, when one went the others would follow
shortly.

I don't have a good solution (in my situation) but I have discovered
several interesting things that may be of some help to you.
I was running my terminals at 9600.  I have found 2 things that will
eliminate the problem for me.  The first is to set a parameter on the 
terminals to limit the transmit speed (available on VT220, maybe not
on others).  This option, unfortunately, is not available on the
terminals I am using.  Setting the speed down to 2400 also seems to
eliminate the problem for me (running this way now but not happy with
it).  In my case, it was keys that send character sequences (like the
arrow keys that send ESC sequences) that caused the lock-up.
I have been trying to blame the ports board, the drivers or the
application program I am running, all to no avail.  I am beginning to
think it is a bug in SCO Xenix (I am on 2.2.3).

BTW in the process of experimenting, I have found that killing the
lowest child process assigned to a terminal will "free it up" again.
This is not too practical since my application then gets rather confused
about what is going on and I have to kill everything.  In some cases,
this test could be rather dangerous.  I have had data files corrupted
when I disconnect the terminals or otherwise log them off unnaturally.

I am about ready to prod SCO with this problem.  I took it to them
rather informally about 6 months ago and they pleaded ignorance.
I saw another comment on here about a week ago that was similar to
this but I let it get away from me.  If we could assemble some
data amongst us, maybe SCO would be more responsive.
I have (generally) been very pleased with their tech support in the
past.
Call me if you like. Office number is 217-753-7965.