Decnet+ aka Phase V will talk to HECnet perfectly fine. On Wed, 16 Jul 2025, 08:55 Johnny Billquist, <bqt(a)softjar.se> wrote:

[snip] LOL I have always considered that an upgrade, too Wilm

On 2025-07-16 14:29, Paul Koning 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... Johnny -- 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

I found it in the VMS manuals, and they point to some RFCs. I'll read those. paul

I skimmed those RFCs. It is something entirely different from what we're talking about. What it does is map the DECnet session control interface (the program API) onto TCP connections. More precisely, which is where the Phase V tie-in shows up, it's a mapping of the OSI transport layer, for TP0 in particular, onto TCP. That makes some sense: TP0 is designed to sit on top of a connection-oriented network layer (like X.25). So essentially what this does is abuse TCP as if it were X.25. This isn't anything like the Multinet thing because it sits a few layers higher. There is no DECnet network layer (routing layer) involved at all. This feature only works between two nodes both of which use the feature, and the connectivity between them is a TCP/IP network, not a DECnet network. It would certainly be possible for other systems that support TCP to do this; for example, RSX could do it with your TCP support. If so, you'd be communicating over the Internet directly, not over HECnet. paul

Michael, I “upgraded” to phase IV DECnet on all my HECnet machines - to be consistent across each of the VAX/Alpha/x86 OpenVMS and PDP-11 operating systems (and I can use my 40-plus years of burnt-in NCP command memory to manipulate the configurations). Wiz (aka David Moylan) wiz(a)djm.net.au is the person you should contact regarding joining HECnet area 35 in Australia. He can allocate node numbers and Johnny Billquist co-ordinates the node name registrations. I suggest you use pydecnet as your DECnet protocol router as it can manage the IP tunnels into HECnet. I run it and a few SIMH instances on a Raspberry Pi 3B, whilst my x86_64 OpenVMS runs under virtualbox on my Mac mini. Tony — Tony Nicholson <tony.nicholson(a)computer.org On Thu, 17 Jul 2025 at 14:34, Michael Brown <mbrown(a)b5.net> wrote:

That depends on what you mean. PyDECnet is Phase IV (or III or II, but normally IV) so it interoperates with compliant Phase V nodes by the usual rules. However, PyDECnet does not itself implement Phase V. I've thought about that but it's not an easy job, in part because the set of specifications available is incomplete and also involves ISO specs that cost serious money. paul

To reiterate, you can connect to HECnet perfectly well when running DECnet+. In my case, I use Pydecnet as the local LAN router and this also runs the link to HECnet. Phase IV or V nodes on the LAN talk to the local LAN router and thus also to the rest of HECnet. On Thu, 17 Jul 2025, 16:15 David Moylan, <djm(a)wiz.net.au> wrote:

Well, we all have different motivations for doing retro computing. For me, running Phase V is actually the whole point. I worked on it at DEC, so it's fun to connect today using some code I wrote 30+ years ago. On Thu, 17 Jul 2025, 20:56 Robert Armstrong, <bob(a)jfcl.com> wrote:

Hey, I have similar motivation -- I didn't write any Phase V code but I wrote some of the specs and helped create bits of others. (For example, I bent the mind of the original author of the DTS spec by telling him there is such a thing as "leap seconds".) Also, if you want to know why PyDECnet does some of the stranger things it does (like Phase II support, and partial Phase I support for that matter) my answer echoes George Mallory: "because it is there". paul

Well, there are new applications. One of these days I hope to add DECdts support to PyDECnet. paul

Part of the issue here is related to VMS/x86. The current community prebuilt images only ship with Phase V and from what I understand the libraries are missing for Phase IV so you can’t run it native. The earlier install builds from years ago apparently had Phase IV support - or at least I am lead to believe this. Cheers, Wiz!! Sent from my iPhone On 18 Jul 2025, at 7:19 am, Johnny Billquist &lt;bqt(a)softjar.se&gt; wrote: Fair enough, but as Bob points out - Almost everything on HECnet is Phase IV, so you won't really get any of the benefits of any "enhancements" that happened in Phase V, when we talk about HECnet in as a concept. All you can do is exercise then Phase IV compatibility of your local Phase V node, and suffer the pain of the bugs and incompatibilities of Phase V. And over time you'll realize that there are a few... Johnny On 2025-07-17 22:17, Trevor Warwick wrote: Well, we all have different motivations for doing retro computing. For me, running Phase V is actually the whole point. I worked on it at DEC, so it's fun to connect today using some code I wrote 30+ years ago. On Thu, 17 Jul 2025, 20:56 Robert Armstrong, &lt;bob(a)jfcl.com <mailto:bob@jfcl.com>> wrote: running DECnet+. You can, absolutely, but just to be clear HECnet as a wholeis only Phase IV. When you connect a Phase V node to HECnet you only get Phase IV functionality to the rest of HECnet. Like most people I agree that Phase V is not worth the trouble. I wonder how many Phase V nodes there actually are on HECnet? Bob _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se <mailto:hecnet@lists.dfupdate.se> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se <mailto:hecnet-leave@lists.dfupdate.se> _______________________________________________ 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

Hello Wiz I've had progress installing pydecnet, made another linux virtual machine to run it and act as the router. I just got the binary install and it seems to work fine. Using the sample pydecnet.conf I've managed to get it to run and sees the other decnet machines on the lan so I suppose it must work fine with this Phase V installation. I think I just need appropriate .conf file with needed details to connect to HECnet and it's ready to go. I would like to press ahead with this, I will email you directly. I am on the east coast, I'm in Newcastle. On 18/7/25 01:15, David Moylan wrote:

Um... No, PyDECnet does not tunnel DECnet ethernet packets over IP. You're thinking of my bridge program now, and for sure PyDECnet can also handle such connections. But PyDECnet can also talk DECnet itself, has its own node number, and is actually routing DECnet packets, encapsulating them in TCP, in a way that is completely unrelated to ethernet. And this is how most people use PyDECnet, and these kind of links are what we refer to when we say "Multinet" links. Johnny On 2025-07-17 23:02, Tony Nicholson wrote: -- 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

On 2025-07-17 23:28, Robert Armstrong wrote: I'm not sure about that either. My bridge program can definitely do that, though. Johnny -- 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

And reading further down into doc/config.txt it has "--phase-5: applies only to bridge circuits. By default, only DECnet Phase IV packets are accepted from and sent to this circuit. If --phase5 is supplied, OSI packets (802.3 format packets with SAP address 0xFE) are also accepted." So I retract my previous statement (it's been a few years since I read this). Tony On Fri, Jul 18, 2025 at 7:42 AM Tony Nicholson &lt;tony.nicholson(a)computer.org&gt; wrote: -- Tony Nicholson &lt;tony.nicholson(a)computer.org&gt;

It's Billquist with to 'l'. :-D Anyway, a couple of more comments, since we're at this. The bridge program (and by extension PyDECnet when it is talking that protocol) is basically just extending your ethernet segment to cover multiple locations. It just distributes the raw ethernet packets over UDP, and that's it. And it can connect together very many different locations. I don't think PyDECnet can do that last bit, but it can certainly participate as a part of such a bridged ethernet. (The same is also true of simh itself, it can also participate as a part of a bridged network natively). And this is also why it's not entirely recommended to use bridges. While it's simple, and very straight forward, it also comes with a bit of a penalty. The bridge program tries to be clever, and if it knows where another MAC address is, it will only send it in that direction, but any multicast packets will spread everywhere, even if that maybe wasn't always needed. So it can start spreading a lot of traffic out more than needed. And of course, that also means scaling wise, it might get a bit ugly. Now, in reality, it usually is not a problem, and it should in general be reasonable and good. But it's something to be aware of. Compared to a router, it's just spreading things out as if it was local. This also leads to a problem with costs, since costs are on an interface, and not per node. And if you have a bridge where you have one machine on the same physical ethernet, and another machine connected via the bridge, where the machine is halfway across the world, what should the cost of the circuit be? High so that things don't stupidly get routed via you to actually reach something on the other side world, or low, that the next node in the same network don't get router half way across the world... There is no really good answer to that one. And just as a final note of warning. The bridge program does not implement anything like STP. If you create a loop, you'll experience severe pain. *Don't do it* Johnny On 2025-07-17 23:50, Robert Armstrong wrote: -- 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

On 2025-07-17 17:28, Robert Armstrong wrote: That would be fun - I'd love to do a $ LCP SHOW SERVICES and see hundreds of hosts/services. OTOH, tunneling MOP could be an issue - you'd have no control over what version of DECserver software you'd get, unless you're either using a non- standard load image name or are relying on your local MOP server being faster to respond than any other MOP server. Speaking of DECservers, if anyone is interested, here is the most com- prehensive set of DECserver software images / boot PROMs / documentation / pictures: https://www.glaver.org/DECserver Further contributions are wel- come.

On 2025-07-18 00:02, Madeline Autumn-Rose wrote: Not specifically. The DECserver 300 directory has mostly hardware documentation. The DECserver 300 subdirectory in the Pre-DNAS direc- tory tree has the actual load image (V2.2) and the cover letter / in- stallation guide / release notes. The closest match would likely be the DNAS 2.4 Documentation sub- directory, as I'd expect the commands to be similar to those for a 1MB RAM DS90TL (mneng2.sys) or 2MB RAM DS90TL (mneng3.sys). A lot of this was compiled by me from old CONDIST discs, but those generally don't contain the full user manuals, just installation in- formation. The manuals would be on the ODL in Bookreader format (not very useful these days).

Tony... On 2025-07-17 08:04, Tony Nicholson wrote: Thanks for the clarification. I was looking at a machine or two you were running and didn't see any Phase V, but I wasn't sure. :-) Oh, right. I didn't think properly in my initial response. I just saw that you were in area 35 and didn't think to check who actually owned it. So right, David Moyland or Tim Sneddon are the two areas in Australia. I think that would be the smarter option, yes. But it would require spinning up PyDECnet on something. And to answer Michaels other question - no PyDECnet do not speak Phase V as far as I can remember. Johnny -- 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