Hi Johnny et al.
Some new nodes to be added to the HECnet registry please.
BUZZEL 29.113
CORRIN 29.114
Both are VMS 9.2.2 x86-64 running under Debian Qemu/kvm. They are clustered together via shared virtual SCSI discs. Seem to be working quite well.
Terrible timing however, what with the bombshell VSI just dropped about the community licences. I'm tempted to become an Ambassador - I may have something to contribute in the VMS runtime department, along with LLVM. Ah well.
Regards
Keith
I discovered a pernicious boot race condition in FAL. Early in system
start up, only the boot structure (which may not be the login
structure), is recognized by Tops-20. MOUNTR has to start and identify
those other structures which should be made available and their
settings, which it does by looking at where they are persisted in
SYSTEM:DEVICE-STATUS.BIN file. Until MOUNTR has completed structure
identification, any RCDIR% might fail for a non-boot structure. This is
exactly what happens for FAL, which is running asynchronously and
sometimes crashed during start up.
One quick and dirty hack was to simply wait to start FAL, which I did,
but that has its own problems which I won't detail here. I tried some
other hacks, such as doing the mount from the EXEC, which had other
different drawbacks.
The real thing to do is to issue a mount request for the structure from
FAL itself and--once Galaxy is up and running--is processed, will make
RCDIR% safe to do (or safer, anyway). At any rate, there should be no
timing issue in this case. As Columbia's Galaxy programmer in the
1980's and having done some minor work in LCG's Galaxy group in the late
1970's, I actually knew how to do such a request and did so, having
written some sub-routines to issue queue requests for our ID system in
the 1980's.
So, I decided to fix FAL to 'do the right thing' and wound up down
another rabbit hole. I should emphasize "/knew/ how to do", as doing
that kind of Galaxy IPCF request is kind of hairy, particularly if you
haven't done it in four decades. After I looked at it for a while, I
grew despaired at having to relearn it again.
Incredibly, DEC defined a new JSYS called QUEUE% which seemed to do the
trick. Briefly, it performs certain Galaxy requests on behalf of the
user, converting it's simpler calling format to an internal Galaxy
format, getting a PID, and returning the response. QUEUE% does a lot of
cool things, including mount requests. Or at least it's documented to...
Besides having its own bugs, there is no code in Galaxy handle a mount
request from QUEUE%... The simpler format that QUEUE% is using is
actually something that Quasar internally calls a 'short' queue request,
which I had known about back in the day. What happens is that the
QSRQUE module converts it into the regular ('long') format and away you
go. This works fine for printing, plotting, punching, and other kinds
of spooling requests, including batch jobs.
There is no short format for mounting, QSRQUE has no code for this
because mount requests are dispatched to MOUNTR... Nothing is persisted
in the failsoft file. So I wrote a conversion routine to do exactly
that before the request makes it to QSRMDA and thence to MOUNTR.
Naturally doing all that resulted in a hailstorm of other issues as I
pushed things a little farther than they had been designed for.
It happens. I'm working through everything, bit by bit.
Tops-20 has a version of the VMS PHONE protocol that I look at from time
to time.
Is there a published specification for this anywhere? I'd like to maybe
do some work on the Tops-20 code, but I'd prefer not to reverse engineer
what I don't have to.
Besides VMS and Tops-20, what other systems speak PHONE?
I finally got my issues with Comcast straightened out and I now have static IP addresses. They are
IPv4: 50.185.8.122
IPv6: 2603:300b:6c4:21a0:c77b:4f58:27e4:6de2
These are also always available in DNS as decnet.theberrymans.com <http://decnet.theberrymans.com/>
Hopefully, this will be the last change for a while.
Mark Berryman
Area 27
Hi again,
The IP address change has been postponed. Sorry about all this. The IP address of the router will remain at 82.70.71.174 for the next few weeks at least.
Regards
Keith
From: Keith Halewood [mailto:Keith.Halewood@pitbulluk.org]
Sent: 27 January 2024 09:50
To: The Hobbyist DECnet mailing list <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: IP address change for A29RT2 (29.2) - CORRECTION
I have misquoted the new IP address.
Here are the correct details:
The address IP address of A29RT2 (29.2) is changing at around 11:00 GMT today from 82.70.71.174 to 82.71.111.30. DNS updates to geat.pitbulluk.org will no doubt propagate at their own pace.
I have been assured that our IPv6 prefix (for what it's worth) isn't changing.
Please update your multinet 'connects', any IP restrictions on your multinet 'listens' and the far ends of your DDCMP over TCP or UDP connections accordingly, assuming pydecnet.
From: Keith Halewood [mailto:Keith.Halewood@pitbulluk.org]
Sent: 27 January 2024 08:57
To: The Hobbyist DECnet mailing list <hecnet(a)lists.dfupdate.se<mailto:hecnet@lists.dfupdate.se>>
Subject: [HECnet] IP address change for A29RT2 (29.2)
Hi,
Sorry for the incredibly short notice and the wide distribution - this wasn't supposed to happen at all.
The address IP address of A29RT2 (29.2) is changing at around 11:00 GMT today from 82.70.71.174 to 82.70.111.30. DNS updates to geat.pitbulluk.org will no doubt propagate at their own pace.
I have been assured that our IPv6 prefix (for what it's worth) isn't changing.
Please update your multinet 'connects', any IP restrictions on your multinet 'listens' and the far ends of your DDCMP over TCP or UDP connections accordingly, assuming pydecnet.
Regards
Keith
Hi,
Just thought I'd mention that I managed to contact someone who was able to package up and send me a copy of the Algol 68 RS compiler and runtime for VAX/VMS. It works very well under 7.3 and has everything,
including the idiosyncrasies that I remember. Every time I compile something I keep thinking "at last!"
So happy.
Keith
I usually don't send LSSM "new machine" updates here, as we're
getting new hardware up and running all the time, but this is such a
beefy machine that I wanted to mention it here.
Over the past week we've built up a VAX-6460...Six 6000-400
processors, 384MB of RAM, Ethernet, a KDB50, and an RA90, running (for
now) VMS v5.5. And the kicker: an FV64A vector processor board! We've
not done anything with it yet, but it passes its diagnostics and VMS
sees it. We will likely put an RA92 on it and install VMS 7.3 soon.
Interestingly, the vector processor has "PROTOTYPE" stamped all over
it. :)
I'll try to put the vector processor through its paces with FORTRAN
in the coming days.
This machine will be on HECnet whenever it's powered up, as with all
of our other DECnet-capable machines, we just have to pull an Ethernet
cable to it and assign it an address. Assuming the vector processor
runs, people here are welcome to request scheduled run times to log in
and use the machine.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
I have misquoted the new IP address.
Here are the correct details:
The address IP address of A29RT2 (29.2) is changing at around 11:00 GMT today from 82.70.71.174 to 82.71.111.30. DNS updates to geat.pitbulluk.org will no doubt propagate at their own pace.
I have been assured that our IPv6 prefix (for what it's worth) isn't changing.
Please update your multinet 'connects', any IP restrictions on your multinet 'listens' and the far ends of your DDCMP over TCP or UDP connections accordingly, assuming pydecnet.
From: Keith Halewood [mailto:Keith.Halewood@pitbulluk.org]
Sent: 27 January 2024 08:57
To: The Hobbyist DECnet mailing list <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] IP address change for A29RT2 (29.2)
Hi,
Sorry for the incredibly short notice and the wide distribution - this wasn't supposed to happen at all.
The address IP address of A29RT2 (29.2) is changing at around 11:00 GMT today from 82.70.71.174 to 82.70.111.30. DNS updates to geat.pitbulluk.org will no doubt propagate at their own pace.
I have been assured that our IPv6 prefix (for what it's worth) isn't changing.
Please update your multinet 'connects', any IP restrictions on your multinet 'listens' and the far ends of your DDCMP over TCP or UDP connections accordingly, assuming pydecnet.
Regards
Keith
Hi,
Sorry for the incredibly short notice and the wide distribution - this wasn't supposed to happen at all.
The address IP address of A29RT2 (29.2) is changing at around 11:00 GMT today from 82.70.71.174 to 82.70.111.30. DNS updates to geat.pitbulluk.org will no doubt propagate at their own pace.
I have been assured that our IPv6 prefix (for what it's worth) isn't changing.
Please update your multinet 'connects', any IP restrictions on your multinet 'listens' and the far ends of your DDCMP over TCP or UDP connections accordingly, assuming pydecnet.
Regards
Keith
I found Muddle (MDL) repositories on Github and now learned about VMS version in that repository but no binaries.
Does anyone have a copy of Muddle 1.03 for VMS? That allows Zork MDL files to run.
Does anyone have a copy of Scribe or alternative software to interpret MSS document files into printouts?
Thanks,
Tim
