2 Aug
2022
2 Aug
'22
5:49 p.m.
'Real' is an unfortunate word.
If by 'Real', you mean commercial applications that people pay money
for, then I wasn't aware of the DECnet market being very large. I'd
love to be contradicted on this...
That being said, I can truthfully say that if you are interested in
bullet-proof code, then the _best_ thing you can do is a port to another
transport or platform and perform regression tests.
I had code that ran on DOS for years that I ported to the protected mode
under OS/2 1.3. This was more straightforward than it seems because the
Microsoft C version 5 C compiler did just about all of the work and most
assembler didn't need to change. Bugs came hurtling out because of edge
cases that bumped into segment limits now enforced by hardware. I
replaced malloc with direct calls to get exact segments sizes and more
bugs showed up. And it was faster than using banked memory, which
surprised us.
I'm finishing a transport addition to Kermit to use Tops-10 and Tops-20
NRT's. Bugs have come flying out because of edge use cases and recovery
and it is now far more robust. This includes it being a TCP/IP client
to C-Kermit.
Same thing with MMAILR (SMTP) over DECnet.
Same thing with FTP over DECnet.
For hobbyist's some DEC OS's never came with a DEC sanctioned TCP/IP
stack. So if you don't have DECnet, you can't realistically talk to
Tops-10 and some others. Probably OS/8, /maybe/ RSTS and whatever
version of RSX you have that Johnny has gotten to. Others?
Talking to these old operating systems has been a gold mine for finding
bugs in Tops-20, supporting CUSPs, Galaxy and DAP. This is nothing
against those programmers, they just weren't given the time to fully
productize some very interesting features.
I'd prefer to have DECnet in Linux for that reason. However, I don't
recall that I ever came across a very stable version of latd and the
client (whose name I've forgotten). Somebody on this list worked on
them I think.
On 8/2/22 11:25 AM, Brian Angus wrote:
I like that idea, although I do wonder how many
"real" applications would really need, want, or even try to support
DECnet directly in these modern times? For the terminal server case
that I am initially interested in building, CTERM and a few network
diagnostic tools would keep me very satisfied, Adding in some file
transfer capabilities would be simply awesome.
It would be really useful even if some of these functions were only
exposed through internal PyDECnet sub-commands instead of being
available system-wide. I've been happily using PyDECnet for a couple
of years, but I haven't yet upgraded to your new test releases, and I
haven't kept up on what all is included in your future plans?
Regardless, I suspect that any somewhat easier way to keep a version
of DECnet running on Linux with even the minimal set of tools would be
appreciated by many around here. How do you think the performance
would be with CTERM written in Python?
On Tue, Aug 2, 2022 at 10:46 AM Paul Koning <paulkoning(a)comcast.net>
wrote:
On Aug 2, 2022, at 10:40 AM, Brian Angus
<brian.angus(a)gmail.com>
wrote:
Hello,
I'm not a programmer, at least not a very good one, and I'm
quite
happy to expose my ignorance in the effort to learn
something new, so I was wondering how real this dependency is on
having Linux kernel support for DECnet. We are quite able to put
DECnet packets out on the wire using various user mode processes
such as with our favourite emulator SimH. I currently run VAX
DECnet on several linux boxes without any special or unusual
kernel shenanigans using a simple TAP ethernet driver. I also use
other non-IP based protocols such as LAT that do not require any
special kernel mode modules, drivers or privileges.
Wouldn't it be awesome if we could install a "simple" DECnet
daemon on Linux and tweak the few user mode commands that we still
use to point to that instead of the special kernel drivers that
are needed today. This is probably just wishful thinking, but a
very simple non-kernel DECnet implementation might help ensure its
survival for a few more decades.
I could well be completely wrong, but I thought I would ask anyway.
What kernel support gives you is the ability to use the standard
"socket" kernel API to communicate using DECnet. User mode code
means a different API.
Now if Linux were to add a way to create a user-mode back end to
sockets, sort of like a socket analog to FUSE (file system in user
mode), then you could do DECnet in user mode and still get sockets.
Hm... SUSE? (Oh well, that acronym is taken...)
paul
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list --hecnet(a)lists.dfupdate.se
To unsubscribe send an email tohecnet-leave(a)lists.dfupdate.se