[HECnet] Downtime next week

[Paul Koning]

Excerpt of message (sent 20 August 2009) by Johnny Billquist:
...
That said, I have also had problems with the Linux DECnet code.
Christine might remember me complaining in the past. :-)
It works fine with VMS, but horribly with RSX (which also is true of the
LAT code).

Although I've not tried doing much with Linux DECnet to RSX it's always 
seemed to work for me when I have tried it. I suspect that any problems 
here are much easier to fix. Even though the main protocol is in the 
kernel (unlike LAT) it's pretty solid code, so anything that needs 
fixing will most likely be in userspace. Most (though not all!) of that 
was written from proper specifications so should be easier to work with 
than LAT.

I think it's all userspace programs that I have had problems with.

Then again ... I've not had any bug reports from anyone about either and 
it's quite hard to fix bugs you don't know about :-P

Sorry, you're right. I think I've only talked with you on perhaps rather
vague terms about the problems I've had.

But as we now have HECnet, this is way easier to work on.
I suggest you log into MIM, and then just try to do a few different things:

1) Try phone to a Linux box. Initiated from both sides.
2) Try accessing files from both sides to the other side.

Neither of these things worked when I last tried.
And that's a start atleast. :-)

That's not too surprising.

The lower layers of DECnet are all well documented, and if you
implement what the specs say it will work.   The application layers
are not such a pretty picture.

DAP (file access) is reasonably well specified.   Unfortunately, there
are lots of options or variations.   What implementers tended to do is
code along the lines of "if I'm talking to VMS then features x, y, z
will be there".   The right way to do this would be to negotiate
feature lists or capability flags, but either DAP doesn't have that or
people didn't bother using it.   File system differences also play a
part, though at least between RSX and VMS that's no excuse, they are
basically the same.   (RSTS is a different matter, of course -- though
it's closer to Unix which helps as far as DECnet/Linux interop goes.)

A bunch of other protocols have no specs, either there simply weren't
ever any that anyone could find, or if they existed they weren't
published.   PHONE and MAIL are examples, as are the remote terminal
protocols prior to CTERM.   For example, if you want to have a remote
terminal session with anything other than VMS (where CTERM is
available) you're into OS-specific undocumented protocols.
DECnet/Linux has support for some of those because I added them,
though I don't think I ever got around to the RSX version.

CTERM is one of those modern protocols that is so complex that doing
what the spec seems to say is no guarantee of interoperability.   But
in general the rule for DECnet protocols was "it's the responsibility
of the spec to be both correct and complete -- conformance WILL imply
interoperability".   (Most more recent protocols have abandoned that
standard of quality, unfortunately...)

Clearly you should feel free to find (or reverse-engineer) the
protocol definitions and make improvements to the DECnet/Linux
implementation.   That's what I did some years ago, which is why
DECnet/Linux can actually talk to a DECnet/E system reasonably well.

        paul