[HECnet] Cisco DECnet routers and NML

[Johnny Billquist]

Hi. More stuff to comment on. Fun!

On 2020-05-05 04:13, Thomas DeBellis wrote:
> 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.

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

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

> I remembered a previous remote terminal protocol (NRT) that I think was 
> available in either late Phase II or Phase III, but only between 20's 
> (and eventually 10's).  It is in no way as rich as CTERM (the difference 
> perhaps being reminiscent of that between FTP and DAP), but it is far 
> less complex.  It appears to have been modeled in some ways along the 
> lines of the Tops-20 ARPA NCP NVT (without the IAC negotiations).  The 
> interface is close enough so that the Tops-20 TELNET program can use it.
> 
> However, the Tops-20 NRT CLIENT (SETHOST) appears to have been 
> effectively abandoned in favor of the CTERM client and this is 
> understandable, given that CTERM was the common platform and corporate 
> direction.  That it is unfortunate as NRT is more efficient.  Most 
> importantly, NRT doesn't have the above annoyances.   But SETHOST needed 
> further productization.  Like FAL/DAP, bugs hurtled out of it as I 
> started using it.  MRC had modified it to assume a 2020 (I.E., Tops-20 
> 4.2) which denied other efficiencies.  Right now, I've got about eight 
> fixes and enhancements in.  It's quite tolerable.
> 
> The other reason for dusting off NRT is that would allow run FAL with 
> the proper credentials as the top-level fork of a separate job.  Right 
> now, it runs privileged, (either SC%WHL or SC%OPR on Tops-20 or JACCT or 
> [1,2] on Tops-10.   Although checking is done, this is still A Bad Idea. 
> The FTP server, for example runs as a top-level fork.  The changes to 
> the Tops-20 NRT server are very small to allow me to do the same thing 
> with FAL.
> 
> If other DECnet based operating systems support NRT, then I would like 
> to know about that.  Right now, the client checks the remote OS and 
> won't connect if it isn't Tops-10 or Tops-20.

RSX have a client.

   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