home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!dtix!darwin.sura.net!wupost!cs.utexas.edu!ut-emx!ibmchs!auschs!awdprime.austin.ibm.com!konopik.austin.ibm.com!konopik
- From: konopik@konopik.austin.ibm.com (Brad Konopik)
- Newsgroups: comp.unix.aix
- Subject: Re: RTS/CTS on the RS6000
- Message-ID: <1992Sep2.050437.20149@awdprime.austin.ibm.com>
- Date: 2 Sep 92 05:04:37 GMT
- References: <BrL162.1pxJ@icsbelf.uucp> <1992Jul18.133420.448@meiko.com>
- Sender: news@awdprime.austin.ibm.com (USENET News)
- Organization: IBM AIX Porting Center, Austin
- Lines: 46
-
- In article <1992Jul18.133420.448@meiko.com> philip@meiko.com (Philip Gladstone) writes:
- >RTS/CTS:
- > Accroding to IBM you have to put an 'stty add rts' in one of
- >the rc.* files to get the rts line discipline. They (support) offered
- >to send me a script that would do this to a list of ttys.
-
- Yikes ! Don't dare put raw "stty add rts" commands in your rc.* files !
- You're machine will hang like a big dog. Austin's Level 3 TTY support has
- a "work-around" that feeds a list of ttys to an "addrts" program which
- opens the port with O_NONBLOCK so you won't hang. You can hook THIS into
- your rc.* files.
-
- This will have to suffice until someone insists that an APAR be opened to
- have this ability from smit (heck, they might have an APAR by now...call
- and see).
-
- >Two questions for the knowledgeable:
- >
- >1) Why is the effect of 'stty add rts' permanenet -- even when
- > done by a user in their .profile to their own tty? Why doesn't
- > login / init / tty subsystem reset on logout/hangup?
-
- RTS/CTS handshaking is not something that is in effect every 3rd login
- and odd Tuesday ! It's usually something that you want permanent.
- Don't blindly do it from a .profile though, get the workaround described
- above.
-
- >2) Why is it so bad to do 'stty add rts' to your own tty when
- > logged in over the network (i.e. your tty is a psuedo-tty)?
- >Philip
-
- I haven't tried it, but this would probably hose flow control. When
- somebody wants to T_BLOCK the pty because input is backing up, the
- T_BLOCK request gets handled by the pacing discipline (aka flow-control
- discipline) closest to the hardware (or by the hardware if the hardware
- can handle it - ala 64-port). Instead of an xon/xoff getting sent
- across the net, the RTS/CTS discipline tells the pty driver to drop RTS,
- which it does (and which does NOTHING to pace incoming data). DISCLAIMER:
- I haven't traced the code, but this is what I'd expect to happen (your
- mileage may vary - especially if you use weird stuff like pty packet mode).
-
- --
- tcpnet: konopik@konopik.austin.ibm.com | Brad Konopik
- ibmvnet: KONOPIK at AUSTIN | IBM AIX Porting Center, Austin
- internet: konopik.austin.ibm.com!konopik@ibmpa.awdpa.ibm.com
- uunet: ..!uunet!ibmsupt!ibmpa!konopik.austin.ibm.com!konopik
-