On 2022-11-22 06:02, Thomas DeBellis wrote:
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.
[...]
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).
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...