NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/vmsnet/misc/1173

Internet Message Format | 1993-01-23 | 3.7 KB

Xref: sparky vmsnet.misc:1173 vmsnet.internals:1786 comp.sys.dec:7086 comp.org.decus:1136
Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!sdd.hp.com!crash!cmkrnl!jeh
From: [e-mail]
Newsgroups: vmsnet.misc,vmsnet.internals,comp.sys.dec,comp.org.decus
Subject: Re: Need faster async board...dlv11-J?  Something else?
Message-ID: <[e-mail]>
Date: 22 Jan 93 15:18:34 PST
References: <[e-mail]> <[e-mail]>
Distribution: world
Organization: Kernel Mode Systems, San Diego, CA
Lines: 66

In article <[e-mail]>, [e-mail] (Don Stokes) writes:
> [e-mail] 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:  [e-mail], or [e-mail]  Uucp: uunet!cmkrnl!jeh