From: CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 26-APR-1989 03:53 To: MRGATE::"ARISIA::EVERHART" Subj: Re: Terminal line hardware flowcontrol Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Tue, 25 APR 89 23:43:57 PDT Received: from ucbvax.Berkeley.EDU by KL.SRI.COM with TCP; Tue, 25 Apr 89 23:45:11 PDT Received: by ucbvax.Berkeley.EDU (5.61/1.36) id AA14974; Tue, 25 Apr 89 23:32:49 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-vax@kl.sri.com (info-vax@kl.sri.com) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Apr 89 22:48:11 GMT From: scubed!simpact!jeh@ames.arc.nasa.gov (Jamie Hanrahan) Organization: Simpact Associates, San Diego CA Subject: Re: Terminal line hardware flowcontrol Message-Id: <332@simpact.uucp> References: <8904181056.AA00811@ucbvax.Berkeley.EDU>, <288@simpact.uucp>, <474@gp.govt.nz> Sender: info-vax-request@kl.sri.com To: info-vax@kl.sri.com X-NEWS: simpact comp.os.vms: 1380 Path: simpact!jeh From: jeh@simpact.uucp (Jamie Hanrahan) Newsgroups: comp.os.vms Subject: Re: Terminal line hardware flowcontrol Message-ID: <331@simpact.uucp> Date: 25 Apr 89 22:20:30 GMT References: <8904181056.AA00811@ucbvax.Berkeley.EDU> <288@simpact.uucp> <474@gp.govt.nz> Organization: Simpact Associates, San Diego CA Lines: 107 In article <474@gp.govt.nz>, gpwrdcs@gp.govt.nz (Don Stokes, Govt Print, Wellington) writes: > In article <288@simpact.uucp>, jeh@simpact.uucp (Jamie Hanrahan) writes: >> >> (quote from my note about CTS flow control) > > No.... Oh, boy. I wouldn't ordinarily do this, but I don't want net readers being confused by facts-which-are-not-so. So, one point at a time: > Full modem control refers to the handling of DSR & DTR, not RTS & > CTS. Don is mistaken. The devices listed in the SPD as providing "partial" modem control are those which implement only DTR, RI, and CD. Those providing "full" modem control are those which support DSR, RTS and CTS in addition to the first three. We have some of each type (that is, some "full" and some "partial", not the whole list of "full"s that I cited), and the hardware doc for them confirms this. If you're looking at Table 8-3 in the I/O User's Reference Manual, Part I, its terminology is misleading; "All" refers to "partial or full modem control muxes", not all muxes. (Table 8-1 seems to be hopelessly confused. I can understand "Full" vs. "No" for "International Modem Control", but for the DMF32 it says "Yes", and it doesn't say a thing about "partial" support. It also says "No" for the uV2000, but this is one of the machines which I've tried personally, and RTS/CTS works on it as described below. The SPD gets it right for the muxes it mentions but fails to say either "full" or "partial" wrt the uV2000. Hmmm.) > VMS just does not support RTS/CTS flow control, I'm afraid that this is one of those "facts" which "everyone knows" (mostly because a lot of DEC folks say it). It ranks right up there with "You have to spend $25K for the magtape source kit before DEC will sell you the listings fiche" (quoth many DEC sales types). Both "facts" are false. VMS most certainly DOES support RTS/CTS flow control. See the descriptions of these signals in the aforementioned Table 8-3. The reason that many people are confused on this point is that when they think about "RTS/CTS" flow control they usually think about how these signals are used on an old-style half-duplex modem. VMS does not support half-duplex modems. But VMS *does* support RTS/CTS for full-duplex modems. Specifically, it drops RTS briefly when a port goes into the "idle" state, and raises it again on entry to the "wait" state. See Figure 8-1 (same book). Now, VMS does NOT, for example, raise RTS when a write QIO has been queued, and drop it when no more write QIOs are pending, as would be appropriate for old-style Bell 202 half-duplex modems. But that's ok, since the VMS terminal driver provides NO support for half-duplex modems. It supports full-duplex modems, and for full-duplex modems it implements RTS/CTS . As far as CTS goes, I said: >> but many of DEC's terminal muxes DO support hardware flow control, in >> that the port will only transmit data if Clear To Send is true. If >> whatever's connected to the port drops Clear To Send, the port will >> stop sending until CTS reappears. And this is absolutely valid. I and others, collectively, have personally verified this with all of the muxes I mentioned. I've watched it work with a Telebit Trailblazer in uucp "g" spoofing mode, which REQUIRES CTS flow control with the setup I'm using. When the modem's buffers clog up, it drops CTS, and the VAX obediently stops sending. When the modem's buffers clear, it raises CTS, and the VAX resumes sending, mid-QIO-buffer. Works like a charm, both under V4.7 and V5.0 and 5.1. (I don't know how far back it goes.) Rather than depend on watching the modem's LEDs, I put an HP 4954A line analyzer on the circuit. It has a display that shows the modem control signal transitions in a manner similar to what you'd see on a logic analyzer or oscilloscope, with the data sent by the DTE and DCE shown in proper time relationship to the control signal transitions. It confirmed what I thought I was seeing in the LEDs. (That's how I know that the pause was mid-buffer; I could see the data.) Before trying the Trailblazer I tried it with a breakout box. Same result. Since this is an area of some concern to me, and since the doc did not come right out and SAY that the VAX would stop sending when CTS went low, I've also spent some time at DECUS talking to some of the folks who wrote the terminal driver. They confirmed what I've said above, and told me where to find the supporting code in the driver. I looked. It's there. > , although I gather > it has been done, and TSC tell me that there is some unsupported handling > of RTS/CTS in the DMB32, It most certainly has been done, and with standard hardware and unmodified drivers. And the folks responsible for the software said that it WAS supported. This would not be the first time that TSC has been wrong. > but I couldn't get it to work. If you're depending on the VAX toggling RTS to indicate the presence of write requests, no, it won't work. But if the port is set to /MODEM and it won't stop sending when your DCE drops CTS, and your DCE is sequencing all other control signals properly, something's wrong. Maybe some bit in TTY_DIALTYPE, or something else of that ilk, is doing you in. But it's *supposed* to work. It certainly works here! > However, some terminal servers are capable of flow control. I think the > DECserver 200/MC will do it; don't know about the DECserver 500. I have no direct experience with terminal servers. Those who have tell me that it depends on the line cards used: Just as in the VAX, some support modem control, others do not. Those that do support modem control support RTS/CTS in the manner described above, that is, exactly like the terminal muxes which provide "full" modem control.