HECnet

hecnet@lists.dfupdate.se

15556 discussions

IP Address change for A29RT2 (29.2) tomorrow (27th Feb) at 11:00 UTC

by Keith Halewood

Hi, There will be an IP address change for inbound/outbound DMC, Multinet, GRE and GRETAP connections to A29RT2 (29.2) tomorrow (27th Feb) at around 11:00 UTC. 82.70.71.174 will change to 77.104.155.22 There will be no change to the IPv6 prefix... apparently. Please update your routers accordingly... and keep the previous config around, just in case. What could possibly go wrong? Regards Keith

11 months

DECnet traceroute for RSX

by Johnny Billquist

I just wanted to let people know that I've just created a traceroute for RSX. Available also as an RPM. It can trace the route from yourself to somewhere, but also do tracing from one arbitrary node to another. So you can explore the different paths in both directions. Example: .trd frodo Trace DECnet route Tracing from 1.21 (JOCKE) to 30.1 (FRODO) 1: Tot: 0 1.21 (JOCKE) 2: Cost: 5 Tot: 5 1.13 (MIM) 3: Cost: 3 Tot: 8 1.1023 (ANKE) 4: Cost: 10 Tot: 18 30.15 (CBVRP3) 5: Cost: 3 Tot: 21 30.1 (FRODO) Hops: 5 Total cost: 21 .trd frodo pondus Trace DECnet route Tracing from 30.1 (FRODO) to 1.15 (PONDUS) 1: Tot: 0 30.1 (FRODO) 2: Cost: 3 Tot: 3 30.15 (CBVRP3) 3: Cost: 6 Tot: 9 1.1023 (ANKE) 4: Cost: 3 Tot: 12 1.13 (MIM) 5: Cost: 5 Tot: 17 1.15 (PONDUS) Hops: 5 Total cost: 17 . A couple of comments: 1. This all works by talking to the NICE server for each node along the path. 2. If a hop does not have a NICE server, it will not be possible to query beyond that point. This typically happens if there is a CISCO router in the path. 3. Your local node needs to have a nodename of all nodes along the path, or else the program cannot connect to the NICE server of that hop. 4. If NICE do not give a next hop for a node, the program tries to instead query about the destination area. If that also fails, then the tracing fails. This happens with with older versions of PyDECnet. So in order to make some diagnosing of things on HECnet a bit easier, please update your PyDECnet routers to a somewhat recent version everybody. Suggestions on improvements, as well as bug resports are most welcome. The code is written in C, and isn't that large. At the moment is's a bit hacky, but I might eventually clean it up some. But it means if someone wants to port this, it's not completely impossible to do so. 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

11 months, 2 weeks

Reminder about nodename updates

by Johnny Billquist

Hi. I thought I'd just refresh people about how to update nodenames on their machines with the latest information in the most simple way for different OSes. The basic information can be read at http://mim.stupi.net/hecdb.htm. Note that there are specific files in the appropriate form already prepared for most any OS, so you do not need to grab MIM::HECNET:NODENAMES.DAT and do a bunch of parsing and processing yourself. Doing that is just making something simple more complicated on your side. If you have need for other formats of the data, or spot something that could be made smarter/better, just let me know and we can work together to get whatever is needed. The different files mentioned in http://mim.stupi.net/hecdb.htm are all automatically generated whenever any change to the nodename database are done. The actual database is in Datatrieve-11, and then I have a makefile under RSX to generate all the different files. Doing changes to the content of a file, or adding new files with other content/formats are very easy for me. Also, the mailing out to people with a notice when the database change are also automated, and if anyone wants to be notified when the database change, just let me know. However, at this time, there are some issues with delivering mails to users of gmail. Google is not accepting mails from Mim, because SPF and DKIM is not setup for Mim. I should ping Peter about this, but until that is resolved, be aware that mails from Mim to gmail might not get 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

1 year

Some new nodes

by Keith Halewood

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

1 year

PANDA II Current Status

by Thomas DeBellis

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.

1 year, 1 month

VMS Phone Protocol

by Thomas DeBellis

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?

1 year, 1 month

Area 27 IP address change (yet again)

by Mark Berryman

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

1 year, 1 month

Re: IP address change for A29RT2 (29.2) - CANCELLED

by Keith Halewood

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

1 year, 2 months

Algol 68 RS at last

by Keith Halewood

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

1 year, 2 months

happenings at LSSM

by Dave McGuire

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

1 year, 2 months

← Newer
1
2
3
4
5
6
7
8
...
1556
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet