5 May
2020
5 May
'20
11:30 p.m.
On 2020-05-05 22:55, Paul Koning wrote:
Realized that later, as I started poking around at the clients I had for
RSX and found RVT, which is for talking to VMS...
I guess that might be. It's obvious they had some grand ideas anyway.
Yeah, all of these programs under RSX is in the "unsupported" category,
but provided. Which is nice. That RSTS/E baked them all into one is
definitely much nicer than the RSX solution. Not sure why they did it
the way they did.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On May 5, 2020, at 2:18 PM, Johnny Billquist
<bqt at softjar.se> wrote:
Hi. More stuff to comment on. Fun!
On 2020-05-05 04:13, Thomas DeBellis wrote:
VMS had a pre-CTERM protocol, similar in style to RSX (in other words, roughly an RPC
version of $QIO) but with VMS QIO semantics instead of RSX ones. RSTS supports that one.
Let me clarify this a bit. Leaving LAT aside,
Tops-10 and Tops-20 implement two remote terminal protocols for DECnet. The Digital
common one is CTERM, which runs on all (or most) platforms. Unfortunately, there are some
minor problems with the current Tops-20 CTERM implementation that are annoying. For
example, you can't use space as an un-pause character, which I've been doing since
about 1978. Fixing it (if possible) means I've got to wade into the monitor and that
could mean months before I come back up for air.
Right. And RSTS/E had its own protocol, as did RSX. And they were all sortof optimal for
each system.
The VMS came with CTERM, and everyone was expected to do that one, and it's more akin
to an RPC-based system than some kind of terminal. The original concept of CTERM is that it's a two
layer system, which is why there are two specs. The foundation layer provides the common
machinery, then CTERM (command terminal) is an operating mode for carrying command line
style terminal interaction. The idea was that other modes would be created for screen
editing (EDT style) and forms (like what FMS-11 supports). I don't think that ever
happened, so we're left with a very heavy protocol to do only a piece of what was
originally contemplated.
I think I might have looked at some specs at some point, but long long
ago, and I can't remember much of anything.
At one point DEC built a PDP-11 based terminal server
that speaks CTERM. It worked, after a fashion, but it was so large, expensive, and slow,
that Bruce Mann decided to see how quickly he could do better. That's how LAT came
into existence. The resulting turf war was quite spectacular.
That war would have been interesting to see. LAT performs rather well I
must say, so Bruce Mann definitely did something better.
CTERM definitely is overengineered, and also smells like designed by a
committee...
But, ugly as
it is, it's the closest to some kind of lingua franca. But I think CTERM have issues
on every system except VMS (I don't know, they might have problems even with VMS only,
who knows? CTERM is ugly.)
I suppose, though quite possibly the old VMS-specific NRT would have worked just as well
as a lingua franca. That wasn't done because the goal was to do something much
bigger. It's a bit like the long data packet headers in
DECnet Phase IV -- there is lots of cruft in there that anticipates a whole lot of
features that were never created, or even specified.
The DECnet protocols are not bad in some areas. There was definitely
some good thinking going into extensibility and backward compatibility.
It is, however, a bit awkward when writing programs and debugging. Maybe
there were better tools available somewhere, but for the most part, I
just write stuff in blindly and test until I start getting it to play.
TCP/IP is nice in that way, if we talk about the old protocols. Text
based, and you had telnet. So it is really easy to test and play around.
I guess that is mostly going away now, with TLS and all the binary
protocols coming.
But RSX ships
with the system specific remote terminal clients as well, so I have a client for talking
to TOPS-20 using that protocol, and a client for talking to RSTS/E using that protocol...
RSTS does a bit of connect-time magic to allow all four modes to be packaged into a
single client program. So if you install the "unsupported" version, the
"set host" command just magically works no matter wich host you're dealing
with, so long as it has a server installed for the old protocol.