[HECnet] DECnet for Linux Bug Fixes

Thomas DeBellis tommytimesharing at gmail.com
Fri Nov 6 18:45:39 PST 2020


No, the application code base is nothing alike; the monitor level code 
is, oddly enough.

I don't know about NFT; it's on my list of DECnet utilities to fix.  
There appears to be a new file transfer facility implemented in BLISS 
called FTS.  That might be shared, but it really doesn't seem to do much 
of anything on PANDA.  I have yet to look at it; much of the other user 
mode DECnet code is not really productized and I've been focused on that 
(I.E., it's buggy).

However, it is impossible that DAP or FAL are shared.  FAL is 
multi-forking, which Tops-10 cannot support (it actually runs FAL as 
separate jobs off of Galaxy, which I think is a great idea). DAP is 
completely Tops-20 based; it uses PMAP% (I.E., non-Tops-20 I/O).  I 
strongly suspect that NFT does not share a common code base; at least 
that's what I recall from the last time I was maintaining it in the 1980's.

I did have to make a few changes to DAP to keep it from confusing RSX.  
Johnny was a huge help there.  Tops-20 DAP is noticeably lacking RENAME; 
it's something I want to put in, put I wanted ANONYMOUS first.

Both Tops-10 and Tops-20 use GLXLIB to implement certain functionality 
(memory management comes to mind), but the respective Galaxies has 
diverged over the years; in some cases, significantly.  They're clearly 
from the same universe, though. (Boo)

Some of the monitor code is the same and has conditional assembly.  It 
appears to have been debugged in user mode under Tops-10, then ported to 
Tops-10 monitor mode and then ported to Tops-20 monitor mode.

I have a guest account on a very fine Tops-10 machine with source, but 
I've only really looked at part of Galaxy thus far; not any DECnet 
utilities.

On 11/6/20 7:42 PM, John Forecast wrote:
>> On Nov 6, 2020, at 6:45 PM, Thomas DeBellis <tommytimesharing at gmail.com> wrote:
>>
>> If you don't mind experimental code, you can anonymosly test it against my modified Tops-20 DAP/FAL server.
>>
>>
>> It’s actually the other way round, TOPS-10 NFT talking to Linux FAL. I haven’t tested with TOPS-20 yet but my understanding at the time was that both TOPS operating systems shared common application level code. What version of DAP does your FAL server implement?
>>
>>     John.
>>
>> You can contact me offline to set something up.
>>
>> On 11/6/20 2:47 PM, John Forecast wrote:
>>>> On Nov 6, 2020, at 10:20 AM, Paul Koning <paulkoning at comcast.net> wrote:
>>>>
>>>>
>>>>
>>>>> On Nov 6, 2020, at 3:55 AM, Johnny Billquist <bqt at softjar.se> wrote:
>>>>>
>>>>> On 2020-11-06 02:55, Paul Koning wrote:
>>>>>>> On Jun 29, 2020, at 8:45 PM, John Forecast <john at forecast.name> wrote:
>>>>>>>
>>>>>>> Recently I have found, and fixed, a number of bugs in the DECnet for Linux kernel module. Some of
>>>>>>> these bugs may be relevant for members of this mailing list who are using DECnet for Linux,
>>>>>>> especially on a Raspberry Pi.
>>>>>> I've spent a bit of time with John's latest code to see how it works on other platforms.
>>>>>> The answer is "quite nicely".  I dropped his changed files into a Fedora Core 32 (the latest release, as of a couple of weeks ago anyway) sources, and built their 5.8.17 kernel with DECnet enabled, for 64-bit x86.
>>>>>> It works, no major problems seen.  This is the endnode; I haven't tried a router yet.
>>>>>> Very nice.
>>> I’ve never even built the router version of the code. It is marked “experimental” in Linux config.
>>>
>>>>> I had serious problems using it to talk to RSX in the past (many years ago). Have you tried accessing in both directions between an RSX node and that? It might be it has been improved a lot since I tried, but I am a little concerned that it's mostly just been tested against VMS.
>>>> You're right, the initial testing was against VMS, but it wasn't all that long after that I spent a bunch of time getting it to work better with others.  For example, that's why the "old remote terminal protocol" is implemented in Linux.
>>>>
>>> It also tries to pretend that it is VMS, both nml and fal. I’ve written new versions of both; nml2 no longer responds to VMS system specific commands and fal2 mostly uses user-defined codes for OS and file system types (TOPS-10 and, probably TOPS-20, complain about unknown remote system types and generate bad directory listings so for those systems it claims to be Ultrix-32).
>>>
>>>> Just tried some tests.
>>>>
>>>> RSX to Linux: NCP works, LOOP NOD (mirror) works, SET HOST works.  DAP doesn't, it gets "Tasks out of synchronization".
>>>>
>>>> Linux to RSX: mirror works, cterm works, dap works.
>>>>
>>>> RSTS to Linux: NCP works, LOOP NOD works, SET HOST works.  DAP fails with a message indicating an Interrupt message is mishandled.  (DAP is one of the few protocols that uses interrupts.)
>>>>
>>>> Linux to RSTS: mirror works, cterm is not supported by RSTS, "sethost" doesn't work because the connect fails in a way that doesn't reach the check for "no such object" status.  DAP partly works, but the directory listing only shows the last file rather than all of them.
>>>>
>>>> Haven't tried VMS yet, the VMS system I have access to seems to be down right now.
>>>>
>>>> 	paul
>>>>
>>>    John.
>>>


More information about the Hecnet-list mailing list