[Re-sending as there's an unfortunate interaction between mailing
lists and my multiple email addresses, so this didn't make it to the
list.]
On 2025-07-17 00:00, Terri Kennedy wrote:
> On 2025-07-16 18:42, Johnny Billquist wrote:
>> Paul, any reason why you think DEC would have done the same thing
>> Multinet did, which is DDCMP inside TCP with 4 byte headers, two being
>> length, and two just ignored?
>> As we've discussed plenty of times in the past, the Multinet solution
>> is really a bad back and abuse. And I've never heard anyone reporting
>> to have connected a Phase V node's DECnet-over-IP to a Multinet Phase
>> IV node DECnet-over-IP.
>>
>> It's not about the compatibility between the implementations of DECnet
>> in the phases, but about how you encapsulate the whole thing if you
>> want to use TCP as the carrier...
>
> I've been aware of the MultiNet implementation since it was known as
> Phase-IP during its field test. I can't speak to the specific reasons
> for the design decisions TGV made back then. I'd assume that they did
> it that way so that DECnet itself could handle both routing (packet
> comes in via TCP/IP, goes back out over a synchronous link) and do all
> of the validation / retry / whatever stuff in DECnet. Remember, this
> was before Phase V reared its ugly head. We had (at least) CMU/Tek,
> MultiNet, TCPware and Wollongong all competing with each other (and
> with UCX once it reared its ugly head).
>
> Having said that, MultiNet is an odd mishmash of a thin layer of VMS
> veneer on top of other code that looks vaguely TOPS-ish - the "?Not
> confirmed" stuff, the fact that ^Z doesn't exit in a lot of places, and
> so on. It had the UCXDRIVER and UCX emulation library so that things
> that depended on DEC C library networking routines would still work*,
> like X11 transport over IP.
>
> PMDF also has the same sort of weirdnesses, even though it originated
> elsewhere. Both PMDF and MultiNet are developed/supported by Process
> Software.
>
> This also led to what essentially amounted to forks of BIND, SSH,
> etc.
> as none of the MultiNet changes were accepted upstream. MultiNet was
> still running BIND 4.9.7 long after the rest of the world moved on,
> for example.
>
> When Process took over MultiNet from TGV, apparently large portions
> of the code are the equivalent of the famous Dennis Ritchie "You are
> not expected to understand this".
>
> I was tasked with building an IP cluster of Itaniums for a client
> and asked Process how to set it up from scratch, and they said "We
> have no idea, everybody we know of was replacing UCX", so I had to
> figure it out for myself as I didn't want to install UCX just to re-
> place it with MultiNet immediately after doing CLUSTER_CONFIG. That
> project was eventually abandoned as the RX2620s were some of the most
> unreliable, power-hungry pieces of <bleep> I'd ever run into. Major
> components failed and needed to be replaced during development. That
> project is now running on a single rx2800.
>
> * For quite some time MultiNet provided its own C header files
> which would be #include-ed in user source to directly call the rel-
> evant MultiNet library functions directly. At some point, they got
> rid of those and now use the normal C library functions. This has
> broken quite a bit of SIG tape software and I'm slowly slogging
> through it (starting with my own packages) to get stuff working with
> the DEC C library routines.
FYI,
I'm beta-testing Multinet 6.0 for VAX, Alpha, IA64 and x86, which still has the DECnet over TCP feature.
If Process Software continues to offer a hobbyist licence, that'll be another way of connecting into DECnet for x86 VMS.
Looking good so far. The terrors of SSHD are for this coming weekend.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 16 July 2025 08:55
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet+ Connection
You just need to peer with someone else with DECnet+, which aren't that many...
Johnny
On 2025-07-16 08:11, Michael Brown wrote:
> I installed DECnet+ when I was setting up because it claimed being
> able to do DECnet over TCP.
>
> By poking around with net$configure I found I could get my machines
> to talk DECnet over TCP and I can do all the net related commands. So
> I figured it must be very close to being able to connect to HECnet.
>
> I wondered if it is possible to connect to HECnet using DECnet+, and
> how that might be done ?
>
>
> _______________________________________________
> HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an
> email to hecnet-leave(a)lists.dfupdate.se
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
Last week I discovered that the power supply for PDXVAX had died (VAXstation 4000 m60). I swapped that system out with my spare, and then set about a project I’d been planning for years, so the hardware is now virtual, and won’t need to be shutdown when the weather is too hot. When I booted it temporarily on the other VAXstation I discovered that it looks like I probably need to update my Multinet links. All three connections appear to be down.
I know I was connecting to A2RTR, MIM, and one other.
DECNET-CONFIG>show
Circuit Name IP Destination Cost Hello Timer
------------ --------------- ---- -----------
TCP-0-0 108.65.195.50 6 300
TCP-0-1 130.238.19.212 12 300
TCP-0-2 192.108.202.50 10 300
Any help getting back online would be appreciated. Hopefully this is just a case of IP addresses having changed over the last 4 years.
-Regards,
Zane
