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

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