[HECnet] Is this the most up to date version of DECnet OS numbers?

[Johnny Billquist]

Thomas, I'm not sure where you got that list from.

It seems slightly mismatching what I can find. Looking at the NRT code 
in RSX (which uses object 23, and is shared by code in RSX for 
connecting to both RSTS/E, VMS and Tops-20), I find this:

1  RT-11
2  RSTS/E
3  RSX-11S
4  RSX-11M
5  RSX-11D
6  IAS
7  VMS


Those are the documented values for the configuration message that I can 
find.

However, extrapolating from this, in NFT/FAL, there is a much more 
extensive list, which seems to align with this list, which contains:

8  TOPS-20
9  Tops-10
10 RTS-8
11 OS/8
12 RSX-11M-PLUS
13 COPOS/11 (TOPS-20 frontend)
14 P/OS
15 VAXELN
16 CP/M
17 MS-DOS
18 Ultrix-32
19 Ultrix-11
20 DTF/MVS
25 Windows NT
26 Linux


Now, Linux is a value I believe I added just based on observation, so 
it's much less official. But I think all the other ones are ones DEC did 
assign. Unfortunately, I think Windows NT was also added by me, based on 
observation of Pathworks. So I do not know what the values between 20 
and 25 could/should be.

But maybe this helps some anyway?

   Johnny


On 2021-11-07 11:23, Thomas DeBellis wrote:
> Since its inception, Kermit-20 (one the first three Kermit 
> implementations) has had the 'limitation' that it will only talk to a 
> remote Kermit via a physical terminal line (I.E., something like 
> TTY6:).  It doesn't do network terminals in part because it has no code 
> to handle the out-of-band or meta-data that one finds on TVT's (like 
> IAC's) or CTERM's.
> 
> This doesn't exist for the early NRT terminals which were implemented 
> for Tops-10 and Tops-20.  Once you've read the initial configuration 
> message and decided what to do, you basically never have to bother with 
> meta-data.  Because I'm trying to look at an NFT issue between Tops-10 
> and Tops-20, I needed another transport mechanism and modifying 
> Kermit-20 to do DECnet 36 NRT's seemed like an easy hack.  Since Tops-10 
> Kermit isn't making an outgoing connection, it is none the wiser.
> 
> Thus far, it has been fairly straightforward.  Right now I'm just 
> catching the few cases where certain operations don't make sense or 
> otherwise wouldn't work (like setting the terminal speed). Another thing 
> I'd like to prevent is Kermit-20 bothering non-36 bit systems.  This is 
> easily enough done by checking some 'magic' bits in the initial 
> configuration message and restricting by OS type.  This raises two 
> questions:
> 
> First, is the list below complete?  What about Ultrix and ... what else?
> 
>       1    RSTS  2    RT-11  3    RSTS/E  4    RSX-11S  5    RSX-11M
>       6    RSX-11D  7    IAS  8    VMS  9    TOPS-20 10    TOPS-10 11   
>     RTS-8 12    OS-8 13    RSX-11M+ 14    MCB
> 
> Second, the configuration isn't well documented.  Actually, I'm not sure 
> if it's documented, period.  All I have is are some notes that Johnny 
> wrote up in the process of reverse-engineering it and very kindly gave 
> me.  They are certainly fine for this particular implementation, but I 
> was just wondering what else there might be. Plenty for LAT and CTERM, 
> but I don't think I've stumbled over NRT.
> 
> 

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