🚀 go-pugleaf

In article <14012022@zl2tnm.gen.nz>, don@zl2tnm.gen.nz (Don Stokes) writes:
> jeh@cmkrnl.com writes:
>> Mark Pizzolato and I were looking at using the new COMMSYNC characteristic.
> 
> Ummm, can you do a version that uses something that doesn't require versions
> of VMS that won't fit on my system disk?  8-(

Can probably make it dependent on version.  

> TT2$M_BLOCK seems like a good one to me ... who the heck uses it?
> (Famous last words!  8-)

There was a VT1xx terminal that worked in block mode... I want to say VT105,
but that was a half-assed attempt at a graphics terminal.  

> 'course if MACRO source is available, hacking such things isn't difficult...
> 
> What's COMMSYNC _supposed_ to do?

Implements flow control for outbound data based on, I believe, the DSR 
line.  The idea is that if you have a serial printer that waggles DTR for
flow control (which is fairly common in PC stuff; Diablo or someone like that
did it early on, and lots of others followed suit, even though it isn't 
standard) you can wire this to the DTR input of the VAX port.  I don't know
why they bothered since wiring it to CTS always worked fine for me. 

>> 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.  
> 
> Hmm.  I thought it did.  Mind you, I haven't really played with it.

I'll have to test it more thoroughly.  

> The half-duplex method requires that [RTS] be held low unless transmitting
> (or at least preventing the other side sending).  

And is therefore useless!  For our purposes anyway.  

>> 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... 
> 
> Nah.  The spec they were reading from says they should do this.

That's never stopped them before.  Presumably the folks who designed the
terminal server firmware had access to the same spec, but they came up with a
different interpretation.  Several different interpretations, in fact.  In the
16-line version of the DS700, the only way to use EIA-232E-style RTR/CTS flow
control is to use an option where the DS700 ignores CD, in favor of DSR!  
(For one client who was stuck with one of these, I ended up making several 
"adapters", basically a 2" long DB25 extension cable with one wiring change:
the modem's CD feeds the LAT port's DSR.)

They also put out some release note on, I believe, DS200 3.1 code, talking
about the server "asserting RI [ring indicator]", when RI is of course not
sourced by the terminal server! 

> Don't the newer versions of LAT support [set modem and read modem functions]?
> I thought the newer protocol specs had functions to do this.  
> Whether these are supported
> by current devices or load software (or whether this is a random glitch in
> my failing memory) are of course separate issues....

The spec may have it (haven't read it carefully) but LTDRIVER certainly 
doesn't know how to use it.  

> Personally, I have seen few places where monitoring the signals is actually
> necessary -- mostly all you really need to know is that the connection is
> there (or not) and hand all the other stuff to the drivers.  Monitoring
> carrier for a connection when dialling out is about the only real use I can
> think of for reading the modem signals, and that's only necessary if you're
> using a modem that was dug out of the Olduvai Gorge.

Generally this is true.  However it would be nice if ....IO$M_HANGUP did what
it was supposed to.  

My real beef in this area is that the DHV and LAT implementations of modem
control are *different*.  I care less about exactly what it does than that they
be the same.  As it is, I can't always move a modem between a mux port to a LAT
port and expect it to work with no configuration or programming changes.  

> I can think of several pathological cases with LAT where modem control 
> info and data transfer could be way out of sync.  I
> can see why the LAT folks put this stuff in the "too hard" basket.

I've done some implementations of "remote devices" (a pseudodriver talks to
DECnet which talks to a server task which talks to a real device), and you're
right, synchronization can be a sticky area, especially with multiple classes
of requests (reads, writes, and control functions).  I could understand it if
the implementors had put it on the back burner for the first release.  But
these problems *can* be solved, and they should have been solved by now. 

> For example, if you queue
> a large number of writes, and they're flushed from VMS and now are in the
> server's buffer, and you issue an IO$M_HANGUP, when should the hangup be
> actioned?  The same sorts of problems appear in the other direction.  

Personally I think that (in this case) hangup should cancel all the queued
reads and writes and then drop DTR. In the uucp code we do  a $CANCEL first
before issuing the hangup.  However I would be willing to settle for almost 
*any* interpretation of hangup -- anything would be better than nothing. 
I *don't* want to continue to have to release the LAT port to force a hangup.

And of course DEC hasn't seen fit to offer the LAT code to folks who would be
willing to "roll their own", so we can't address it ourselves, either.  DEC
really needs to be awakened wrt the market's interpretation of "open systems".

> --
> Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
> Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
> Victoria University of Wellington, New Zealand              +64-4-495-5052

	--- 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