I've downloaded copies of pyDECnet from two places:
1: svn://akdesign.dyndns.org/pydecnet/trunk/pydecnet (using svn)
2: http://akdesign.dyndns.org:8080/resources/public/index.html
The current version of code at the svn is revision 653.
The current version of the package is V1.1.0-rc2
Is there a difference between the two?
Which is the best source for pyDECnet?
Also, does anyone have any configuration samples they might care to share. I have a working one but I think I am lacking in creativity to make the most out of pyDECnet.
And while I'm at it, is Supratim's pyDECnet monitor page custom? Because it sure doesn't look a lot like mine. But I wouldn't be surprised that his is or that I messed something up on mine.
http://impvax.duckdns.org/pyrtr/index.html
Thanks!
--
John H. Reinhardt
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 ?
[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
Hello friends,
I will be moving house on June 20th. Therefore, I will be shutting down my HECnet-related infrastructure a few days before that date; I plan to connect them again a few days (or maybe a week) later.
Also, my public IP address will change. “odsw48.mywire.org” will point to the new address, and for my incoming circuits that use the raw IPV4 address, you will have to take that into account. You know who you are 😊
It concerns the following nodes:
29.200 PIVAX0
29.201 PIVAX1
29.202 PIVAX2
29.203 PIVAX3
29.204 PIVAX4
29.205 PIRSTS
29.206 ONAPI4
29.207 VMS046
29.208 PIRTVX
29.209 PIVAXN
29.210 VSIAXP (*)
29.211 PCSAPI (*)
29.212 VAXM8 (*)
29.214 PIZRZV (*)
29.215 PIRSX9
29.221 SERIAL
(*) currently not in use
Thanks for your understanding,
Wilm
# supratim(a)riseup.net <mailto:supratim@riseup.net>
# tomas(a)prybil.se <mailto:tomas@prybil.se>
# bob(a)jfcl.com <mailto:bob@jfcl.com>
# Keith.Halewood(a)pitbulluk.org <mailto:Keith.Halewood@pitbulluk.org>
# johd(a)zeelandnet.nl <mailto:johd@zeelandnet.nl>
# mark.curtis(a)aardvarks-and-platypus.com <mailto:mark.curtis@aardvarks-and-platypus.com>
# bqt(a)softjar.se <mailto:bqt@softjar.se>
# mark(a)theberrymans.com <mailto:mark@theberrymans.com>
# mark(a)matlockfamily.com <mailto:mark@matlockfamily.com>
Ok. I can't seem to raise Peter, and this have been going on and been an
issue long enough.
Do anyone have some alternative location I could run Mim and Anke?
Basically - it needs a a static, public IP address, no port blockings
whatsoever, and some reasonable bandwidth. In addition, the machine
needs to run Linux (a VM would do), its own ethernet interface, and me
having access to the machine as root. Some valid reverse DNS for that
address would be good as well, but I will probably move Mim to my own
domain, so that the name can stay the same in the future if the machine
moves around anymore.
If anyone have such resources available, and willing to provide for the
running of Mim (PDP-11 with RSX) and Anke (PyDECnet), then I'd be happy
to move things over, and get things back to running properly.
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've been digging through a lot of documentation and forum posts that seem to
indicate the DECserver 300 can do TCP/IP (including some Ask The Wizard
posts.
Anyone got pointers to which distribution set to track down this version?
This post
(https://forum.vcfed.org/index.php?threads/decserver-300-management-manual.6…)
seems to indicate an older software dist provides that but I don't know which
version supports that.
--
Madeline Autumn-Rose
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
[I realized I sent this from a different email address
than my list email, so it probably got rejected or held.]
I had planned on holding this off longer, until it was
fully complete, but https://www.glaver.org/DECserver is
a treasure trove of information and firmware for almost
all of the DECserver models.
The firmware is split into DNAS (V3.3 being the newest
version except for the DS700 which has V3.6) and Pre-DNAS
directory trees.
In particular, I think the firmware being requested can
be found in:
https://www.glaver.org/DECserver/Pre-DNAS%20DECserver%20Models%20and%20Firm…
Comments on the future direction of this collection is
welcome.
--
Terri
