22 Nov
2022
22 Nov
'22
6:04 p.m.
On 11/22/22 8:46 AM, Johnny Billquist wrote:
On 2022-11-22 06:02, Thomas DeBellis wrote:
[...]
Trying to remember here, since it's now a few months since I looked at
it. I think that I later concluded that the server might sent an init,
but the client is not expecting/requiring it. Which would suggest that
it might not be sent by all versions, so it's not reliable. I don't
think it sends any INIT either. It just starts running, assuming it
works on a stream of bytes with no further interpretation.
Hum... Well, as I said, I am looking at the Tops-20 monitor code for
the NRT terminal driver (NRTSRV) and the two Tops-20 NRT clients that I
am aware of (SETHOST and Kermit-20). NRTSRV always sends the
configuration message, but it does not wait for any response. The
DECnet connection is immediately handed to an NRT virtual terminal and
an EXEC is started, so as soon as the client reads data after the
connection is open, there will be an EXEC herald for it to display.
NRTSRV has no PANDA modifications. The base SETHOST code has a PANDA
modification to allow it to continue running on a 4.1 monitor, but there
is no change in the configuration check. I have extensively modified
SETHOST, but have yet to put in the change to check transport instead of
version. Kermit-20 is an entirely new Tops-20 NRT client implementation
which performs the transport check properly and only comments on the
remote system type.
The Tops-20 clients have been verified to run against Tops-20
(naturally), Tops-10 and Ultrix (or whatever the Unix system was that I
tested against on HECnet).
Trying to unravel some of this very informative
thread.
[...]
------------------------------------------------------------------------
On 11/21/22 5:52 PM, Johnny Billquist wrote:
You forget fast. :-)
Here is what I wrote in August this year:
[...]
So basically, the TOPS-20 NRT server is not sending anything when
you connect,
Am I understanding you correctly? Are you sure about that? May I
ask you to send me an example where this happens? Paul's
recollection agrees with my experience. But this is mostly me trying to recollect what I found
out in August.
Welcome to middle age!! I can't even remember what I had for
breakfast
today...
I do not know why specifically the TOPS NRT client
under RSX works
this way, but I would assume there is a reason. The RSTS/E, VMS and
RSX clients do expect an INIT packet, and the majority of the code is
shared by all the clients under RSX.
I was wondering if the RSX Tops-20 transport
client might actually be
doing the right thing. As I discussed earlier, the Tops-20 Phase II
server sends no configuration data whatsoever. You get connected to a
PTY and away you go. Maybe this is allow it to work with 1979 era code?
If you really want to, I can go digging in the code
again, or we can
try and find all the mails that were sent in the late summer. :-)
Well, I /am/ curious, but this isn't critical priority. Having completed
fixing NFT, I am now putting those fixes into FAL and repairing the bugs
that resulted from the GLXLIB efforts. Right now, I exploded the IPCF
logging. Not sure how I did that, a lot of stuff made assumptions that
broke when I started explicitly managing PSECTs. Sigh...