From: jeh@cmkrnl.com
Newsgroups: vmsnet.misc,vmsnet.internals,comp.sys.dec,comp.org.decus
Subject: Re: Need faster async board...dlv11-J?  Something else?
Date: 22 Jan 93 15:18:34 PST
Distribution: world
Organization: Kernel Mode Systems, San Diego, CA

In article <9828020@zl2tnm.gen.nz>, don@zl2tnm.gen.nz (Don Stokes) writes:
> jeh@cmkrnl.com writes:
>> Good stuff!  I've been mumbling about doing something along these lines... 
>> I'm going to see if I can complete it and put a nice wrapper around it. 
> OK, but note that I got the TT$M_MODEM!TT$M_HOSTSYNC test wrong.  (It'll take
> the modified path if _either_ bit is set, not both.  Originally, I just coded
> to look at TT$M_MODEM, until I realised that it would only call PORT_XOFF to
> output a BEL if HOSTSYNC wasn't set, dropping DTR until the port was 
> re-initialised, which wasn't quite what I had in mind....)

Mark Pizzolato and I were looking at using the new COMMSYNC characteristic. The
doc says that COMMSYNC shouldn't be used with MODEM, but SET TERMINAL does not
enforce this.  My idea is to do RTR flow control if COMMSYNC, MODEM, and
HOSTSYNC are all set; if HOSTSYNC is set but either MODEM or COMMSYNC isn't,
send xon's and xoff's.  It looks as though this will not interfere with the
standard use of COMMSYNC.  This allows easy switching of the new code with the
existing SET TERMINAL command and $QIO interfaces. 

>> It's a shame that similar things can't be done to add RTR/CTS flow control to
>> LAT ports.  (Like the DHV it already honors CTS, even when it is set to "no
>> flow control" or "xon/xoff flow control", but pin 4 just stays true all the
>> time.)  Unfortunately the LAT terminal port driver apparently has no way
>> to request modem control signal state changes.  
> 
> Uh...
> 
> | Local> help set port flow control
> | DEFINE/SET PORT FLOW CONTROL
> | 
> | FLOW CONTROL specifies the characters or signals that control
> | data flow at your port.
> | 
> | FLOW [CONTROL] {CTS     }
> |                {DISABLED}
> |                {DSR     }
> |                {XON     }
> | 
> | CTS means that CTS/RTS modem signals implement flow control.
> | [etc]
> 
> (This is DECserver 200 V3.1)

Yes, yes, I know that!  btw, it also says 

	When using CTS or DSR flow control, MODEM CONTROL must be DISABLED.

I have never seen a DECserver 200 implement RTR (what is often called RTS) flow
control.  Perhaps the RTS/CTS refers to the old half-duplex method.  

What is odd is that the 200MC *always* honors CTS from the modem (ie stops
sending when the modem drops CTS), just as the DHV and similar ports do, even
if flow control is disabled.  I hope they don't "fix" this... 

But what I originally meant is that I can't manipulate the "DTE sourced"
signals, nor read the "DCE sourced" signals, from the VAX side (ie
IO$_SENSEMODE|IO$M_RD_MODEM, IO$_SETMODE|IO$M_HANGUP,
IO$_SETMODE|IO$M_SET_MODEM|IO$M_MAINT, etc., don't work).  I can't even do
the equivalent of Local> SET PORT nnn FLOW CONTROL CTS, though thankfully,
changing the TT characteristics to turn off hostsync and ttsync have do have
the desired effect.  

	--- Jamie Hanrahan, Kernel Mode Systems, San Diego CA
drivers, internals, networks, applications, and training for VMS and Windows NT
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and 
Chair, Programming and Internals Working Group, U.S. DECUS VMS Systems SIG 
Internet:  jeh@cmkrnl.com, or hanrahan@eisner.decus.org  Uucp: uunet!cmkrnl!jeh
Xref: sparky vmsnet.misc:1187 vmsnet.internals:1800 comp.sys.dec:7123 comp.org.decus:1144