Path: utzoo!mnetor!uunet!husc6!mailrus!ames!ptsfa!pacbell!att-ih!att-cb!clyde!watmath!onfcanim!dave
From: dave@onfcanim.UUCP (Dave Martindale)
Newsgroups: comp.dcom.modems
Subject: Re:  INFO-MODEMS Digest V88 #52
Message-ID: <15568@onfcanim.UUCP>
Date: 4 Mar 88 15:38:22 GMT
References: <8802180550.AA09815@ucbvax.Berkeley.EDU> <40@marque.mu.edu>
Reply-To: dave@onfcanim.UUCP (Dave Martindale)
Organization: National Film Board / Office national du film, Montreal
Lines: 28

In article <40@marque.mu.edu> brianb@marque.UUCP (Brian Bebeau) writes:
>
>No, this doesn't make much sense to me. It's been my experience that
>most DTE devices specify DTR as being *always* on, therefore useless
>for hardware flow control. If the DTE implements RS-232 properly,
>RTS-CTS crossed over will work properly for hardware flow control.
>At least it always did when I was working for a modem manufacturer.

Please note that RTS-CTS flow control is NOT a "proper" implementation
of RS-232.  RTS is supposed to be used by the DTE to request that the
(half-duplex) modem switch into transmit mode, and CTS was a reply from
the modem indicating that it was now configured and stable ready for
transmission.

With full-duplex modems, this pair of functions isn't needed, and the
wires are often used for flow control, and if both the DTE and modem
support this then it's useful.

If you interconnect two DTE's that both use RTS/CTS flow control,
then crossing RTS/CTS in the null modem cable is good.  If the devices
conform to the RS232 standard, though, you want to connecte pin 4 to pin 5
by a short jumper at each end.

Finally, most "real computers" DO implement DTR.  If they only implement
two modem control signals, it will be DTR and either carrier detect or DSR.
When making a null modem cable, it is useful to include DTR, crossed
to DSR and CXR at the other end, so the machine on one end can tell when
the one on the other end has gone away or wants to talk.