Hi Johnny,
I got the list from the SETNOD that came with PANDA, the DEC version 
being _UPD ID= 479, SNARK:<6.UTILITIES>SETHOS.MAC.4,? 10-Feb-84 14:39:12 
by EVANS_.? I should note that this list /conflicts/ with what is in 
DAPSYM. Since my DAPSYM is from 1980, I thought that SETNOD might take 
precedence or otherwise be more 'accurate'.? At least, I didn't remember 
the SETNOD one being wrong from the last time I was hacking it.? Just in 
case, I double checked and It seems OK; take a look at following tests:
    Kermit-20>set line *VENTI2*::
    [Remote system is running /TOPS-20/]
    Kermit-20>set line *VENTI*::
    [Remote system is running /TOPS-10/]
    Kermit-20>set line *MIM*::
    ?/RSX-11M/ type systems do not support Tops-10/20 NRT communications.
    Kermit-20>set line *APOLLO*::
    ?/VMS/ type systems do not support Tops-10/20 NRT communications.
    Kermit-20>set line *BITXOT*::
    ?/RSTS/E/type systems do not support Tops-10/20 NRT communications.
    Kermit-20>
Since I've signed on to every system via CTERM except the last, I know 
those messages are correct.? I have no id for BITXOT::, but it is 
documented to be RSTS/E, so the value 1 there appears correct.? I was 
unable to test with the two RT systems that are documented in MIM:: and 
am not sure what the reject reason means.
    Kermit-20>set line *SEADOG*::
    ?Connection failure, Reject or Disconnect by Object
    Kermit-20>set line *SNOTRA*::
    ?Connection failure, Reject or Disconnect by Object
    Kermit-20>
On the other hand, I don't remember my FAL/NFT/DAP blowing up on the 
wrong system, either (they blow up on plenty of other stuff...)? It 
would appear that there are _two_ (2) separate lists of system type 
bytes, one for NRT and the other for DAP, viz:
     ? NRT??????????????? DAPSYM
     ?1??? RSTS????? .OSRT==1??????? ;RT-11
     ?2??? RT-11???? .OSRST==2?????? ;RSTS/E
     ?3??? RSTS/E??? .OSRXS==3?????? ;RSX-11S
     ?4??? RSX-11S?? .OSRXM==4?????? ;RSX-11M
     ?5??? RSX-11M?? .OSRXD==5?????? ;RSX-11D
     ?6??? RSX-11D?? .OSIAS==6?????? ;IAS
     ?7??? IAS?????? .OSVAX==7?????? ;VAX/VMS
     ?8??? VMS?????? .OSTP20==10???? ;TOPS-20 (^D8)
     ?9??? TOPS-20?? .OSTP10==11???? ;TOPS-10 (^D9)
    10??? TOPS-10?? .OSOS8==12????? ;OS-8 (^D10)
    11??? RTS-8???? .OSRXP==13????? ;RSX11-M PLUS (^D11)
    12??? OS-8
    13??? RSX-11M+
    14??? MCB
Does anybody know what the CTERM list would be?? This disparity is 
unfortunate.? Any speculations as to how it happened?? I'm thinking 
somebody not talking to somebody else, but I really wouldn't have any idea.
 
------------------------------------------------------------------------
 On 11/7/21 6:17 AM, Johnny Billquist wrote:
 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.