Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!amdcad!ames!pacbell!att!chinet!les
From: les@chinet.UUCP (Leslie Mikesell)
Newsgroups: comp.dcom.modems
Subject: Re: need help with xenix Kermit to PC procomm
Message-ID: <6594@chinet.UUCP>
Date: 15 Sep 88 14:28:33 GMT
References: <20302@neabbs.UUCP> <11744@oberon.USC.EDU> <620@wsccs.UUCP>
Reply-To: les@chinet.UUCP (Leslie Mikesell)
Organization: Chinet - Public Access Unix
Lines: 25

In article <620@wsccs.UUCP> terry@wsccs.UUCP (Every system needs one) writes:

>Windowing protocols require large buffers... Xenix has 128 bytes of
>buffer.  Windowing protocols on most multitasking operating systems
>have realtively teeny buffers.  The only way that'll work is with
>some sort of flow control -- either rts/cts or xon/xoff, and xon/xoff
>requires a non-binary protocol.

Don't intelligent serial boards solve this problem?

>The main problem with a windowed 7-bit protocol is that there is no way
>to get out of a kernal-mode xoff (alarms are queued around kernal-mode
>code, and they all go off when you get an xon..) short of putting a
>timer in the driver.  This means you have to handle xoff's in user mode
>code and this puts you in never-never land if you're swapped out.  This
>means no way to gracefully recover.

This is not true for SysVr3 on the 3B2, although I believe it was in
some earlier releases.  Does anyone know specifically when this bug
was fixed so that an alarm() around a write() will bail out if you
have received an xoff.  As I recall from working with a TRS Model 12
running xenix, either the alarm never happened or the ioctl()s or
close() on the line would lock so there was no way to even disconnect.

Les Mikesell