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

[Thomas DeBellis]

There are a lot of features that I'd to lift from other NFT's and FAL's.

The problem is trying to do the modifications within the existing 
architecture.  They've needed a number of modifications to fix bugs, 
even to get them up to the point of stability, let alone have the 
functionality that I've admired in the other implementations.  The FAL 
source went from 25K to 44K of source for stability and debugging fixes, 
but also required an additional module of about 98K for the enhancements 
(such as ANONYMOUS).

NFT is in fact what I'm in the middle of trying to fix, but that source 
is more difficult to work with, largely because it has a parser whereas 
FAL didn't have one until I wrote it.

But I don't really like criticizing any of this, even when it does get 
me peeved.  Development looks like it was stopped quite abruptly.  It's 
almost as if the programmers were yanked away from their keyboards, 
which I'm sure at least a few did not appreciate.

On 11/7/21 9:14 PM, Johnny Billquist wrote:
> Hey. Thanks for those additions. Any machines on HECnet I can check 
> against?
>
> NFT under RSX have this wonderful functionality that seems to be 
> missing in all other implementations:
>
> .nft venti2::/id
> NFT -- Version V9.0
> Local NFARs V8   DAP V7.1 Buffer size=  2064. OS=RSX-11M+ FS=FCS-11 
> DC=Yes
> Remote FAL  V2   DAP V5.6 Buffer size=  4096. OS=TOPS-20 FS=TOPS-20 
> DC=Yes
>
>   Johnny
>
> On 2021-11-08 03:04, John Forecast wrote:
>>
>>> On Nov 7, 2021, at 6:17 AM, Johnny Billquist <bqt at softjar.se> 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.
>>>
>> The current version of DECnet for Linux I maintain on github uses 192 
>> for Linux which comes from the user-defined space so I could 
>> completely avoid any conflicts with standard implementations. 22 was 
>> for MacOS (the original O/S for the 68K and PowerPC) where DEC resold 
>> a third party implementation (Thursby I think). I don’t remember what 
>> we used for DECnet-SCO but that was another official implementation.
>>
>>    John.
>>
>>> 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
>>
>