emrath (12/27/82)
#R:linus:-75900:uiucdcs:13700012:000:917 uiucdcs!emrath Dec 23 18:37:00 1982 I'm a little confused - how can a machine refuse to accept 2 stop characters? I assume you mean that the 2nd one causes the machine to resume output. In this case, changing unix is like treating the symptom rather than the disease. (We had a pathological driver like that here on a CYBER and we got them to change it fast) What if the first ^s gets garbled or lost or something, and you keep receiving data? You have no choice but to send another ^s with no way of knowing which position the remote machine's "toggle" is in. It is clear that the flow control protocol should be to ALWAYS stop when a ^S (stop char) is received. Whether only a ^Q or anything BUT ^S should resume transmission is open to further debate. ^S as a toggle is a big mistake (which unix doesn't make), and I recommend not changing unix to compensate for external systems that are inherently wrong. If you must, make it a non-default option.
dmmartindale (12/31/82)
Sending an XOFF in TANDEM whenever a new character comes in and the input queue is over the high water mark has another side effect - generation of long bursts of XOFFs at high input speeds. At 9600 baud, you can get a lot of characters in the input silo of a DH or DZ before you service the interrupt, and sending an XOFF for every one of these input characters is silly. And running at 9600 baud is quite reasonable - ABLE DHDM's have a 256-byte input silo, so you almost never lose anything.