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

Sun Nov 7 16:43:16 PST 2021

Actually, we might be looking at different things.
So, here is what I'm looking at.

In RSX, the clients are connecting to object 23. After connection, the 
two sides are supposed to exchange configuration messages.

Packets have the following format:

TYPE(8)
   1 = Configuration message
   2 = Control message
   3 = Unsupported message
   4 = Continue message
   5 = Data message
Length(16)

[rest of packet depends on type]

[Configuration packet continues with]

OS(8)
   Values as mentioned before
Versions(5x8)
Session mode(8)
Menu for config(8)

Not bothering showing the format of the other types of messages right 
now. I can dig out some more on that later if needed.

Does this in any way match what you are looking at, Thomas?

   Johnny

On 2021-11-08 01:15, Johnny Billquist wrote:
> I looked at the code in RSX, which have specific versions of the client 
> software for connecting to TOPS, RSTS/E and VMS. Funnily, only the 
> RSTS/E client is explicitly checking the OS field value. Neither the VMS 
> client, nor the TOPS client is checking that. The TOPS client happily 
> connects me to whatever, but with non-TOPS hosts, I get disconnected as 
> soon as I actually type anything.
> 
> But the RSTS/E variant is checking that the OS field have the value 2.
> 
> So I'm really wondering if the field is modified before processing when 
> you receive then. We could of course run some dumps and see exactly what 
> is going over the circuit...
> 
> And I verified that BITXOT is indeed RSTS/E, and responding with what I 
> see as a 2 in the OS field:
> 
> .rrs bitxot
> JOCKE::RRS -- Connection established to node BITXOT::
> 
> RSTS V10.1-L 08-Nov-21 02:27
> User:
> 
> With RT-11, I don't think there are actually any systems online on 
> HECnet. Some people have reserved names for RT-11 systems, but as far as 
> I know, noone have actually located DECnet/RT yet.
> 
> .ncp tell seadog sho exec
> NCP -- Show failed, Listener connect failed, node unreachable
> 
> 
> The list of OSes and values for CTERM are in the documentation, which is 
> online:
> http://linux-decnet.sourceforge.net/docs/found.txt
> 
> The list in there matches what I posted as well. See page 65 for example.
> 
>    Johnny
> 
> 
> On 2021-11-08 00:40, Thomas DeBellis wrote:
>> 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.
>>>>
>>>>
>>>
> 

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