5 May
2020
5 May
'20
7:21 p.m.
Thanks Paul,
As usual, very informative.? What you've verified is Tops-20's monitor
based NRT server implementation, which is good. Therefore, for the
moment, I think it reasonable to assume that the monitor client
implementation is also not suspect.
NI1D displayed the same failure mode as Tron: report of a successful
connection and then, nothing, viz:
% Do not have Control-C capability, proceeding...
Escape character(^Y):
Host name: NI1D
[Connecting to remote host: NI1D]
[Remote system is running RSTS/E]
[Connected: type ^Y to return to node VENTI2]
This shows that the client had a successful connection and handed off to
the monitor.? This was verified by further investigation (with SYSDPY
which showed SETHOST in a WAIT%, pending interrupt from the MTOPR%).?
Since the NRT client implementation eventually hands off to the monitor
for all the data flow, for Initial investigation, I'll have a look at
some that pre-MTOPR% post-connection open logic.? I'll try to do a
little more trouble shooting tonight and see what might be happening.
You mention four 'flavors' (?) of NRT; are these documented anywhere??
(I mean, other than in the code...)
??? ??? --T
------------------------------------------------------------------------
On 5/5/20 9:32 AM, Paul Koning wrote:
Try NI1D, user ID 100,100. I just checked it and TRON, both correctly answer the RSTS
remote terminal protocol.
Keep in mind that the NRT protocol is not actually one protocol, it's four protocols.
At connection setup this is sorted out, if the client side knows how to do that. TOPS,
VMS, RSX, and RSTS are the four flavors. The "unsupported" remote terminal
program on RSTS knows how to do this. I don't know about the TOPS-20 version.
BTW, I just asked NI1D to connect to TWENEX, to verify its TOPS20 NRT implementation.
That works as expected.
paul
> ------------------------------------------------------------------------
> On May 5, 2020, at 1:14 AM, Thomas DeBellis <tommytimesharing at gmail.com>
wrote:
>
> What's fun about the Tops-20 NRT client (SETHOST) is that it doesn't do much
aside from parsing for an escape character and node name. It builds a connection string
and checks to make sure the remote system is either a 10 or a 20. Then it twiddles a few
things on the terminal (a few more if you're running my changes to handle page mode).
Finally, and this is the cool part, it issues an MTOPR% to directly connect the local
user's terminal to the open DECnet connection (port 23).
>
> Thereafter, the client does nothing until the interrupt character is typed or the
connection is broken. So response can be pretty snappy because you are never running in
user space; no context switching. The CTERM client on the other hand is reading and
writing data and otherwise handling the specifics of the protocol in user space. So, more
overhead and more context switching.
>
> As an experiment, I removed the checks for Tops-10 and Tops-20 and tried connecting
to a few hosts on HECnet.
>
> ? Tops-20; TOMMYT and TWENEX worked (of course)
> ? Tops-10; VENTI worked
> ? RSX-11+; MIM accepted the connection and broke it as soon as I started typing.
> ? VMS; LEGATO accepted the connection and broke it as soon as I started typing.
> ? RSTS; TRON accepted the connection and then did nothing. It never broke the
connection, but never displayed any banner or anything else. It appeared hung. So it
would appear that NRT servers only exist on the 36 bit line. Perhaps it's possible to
configure the service for other platforms?
>
> The first few RSTS systems I tried didn't appear to be online; MEZZO, PLUTO,
RSTSE and BITXOT. The few Windows systems I checked didn't appear to be online,
either; WXP, MISSY, KIBBEH and WATAN. I'm not sure if that means they refused the
connection attempt outright.