HECnet July 2024

hecnet@lists.dfupdate.se

8 participants
13 discussions

by Johnny Billquist

I've seen/heard of various stories about how people update their nodename databases on their machines, hacking together scripts, and processing files. So I figured I should write a small mail about the topic (I should create a web-page with this information as well). The main/basic point is that people are creating work for themselves they really don't need. Exactly how you update your nodename database on your machine depends on what OS you are running, but there are basically prepared tools and scripts already existing for pretty much any scenario. And if you happen to have a system or need not currently covered, I can easily create one for you as well. But before going into the solutions, let me explain a bit about the source of the data here. DECnet phase IV do not have a centralized nodename system like DNS. Each node in the DECnet network has its own nodename database, and every machine can have its own name for another machine, independent of what that other machine thinks its own nodename is. However, in order to make it easier for multiple people and machines to talk, it helps if everyone have a somewhat similar database. And here is where the nodename database in MIM comes it. The nodename database that I have on MIM is not the regular DECnet nodename database. Instead I'm using DATATRIEVE to maintain a nodename database, which contains more information than just the number and name. It contains the owner, information about the software and hardware of the node, the location, and when things were updated. This database is what is queried when someone goes to http://mim.stupi.net/nodedb . And that page is generated by just making queries in DATATRIEVE. If someone have a host with DATATRIEVE on it, it is even possible to remotely access this DATATRIEVE database over DECnet (you'll only have read-only access). I have been considering possibly adding a web interface for people to possibly be able to update their own information remotely, but so far that's been a low priority thing. Maybe one day... From this DATATRIEVE database I can then generate the DECnet nodename database on MIM. This is a simple makefile actually. Whenever I run it, it will create a bunch of different files (I'll get to that in a moment), and detect if any changes have happened on the DECnet level of things. If so, it will send a mail to people who have requested it, informing them that the nodename database have been updated, and they should update the nodename database of their own machines. I hope this makes it apparent that creating various files based on the nodename database is actually very simple. This is in a sense what DATATRIEVE is good at. Creating reports is sortof what all these output files are. So - what files do I create today? Well, here is a short list: FIX.CMD - This is a script file suitable for RSX systems using CFE. However, it's sortof specially tailored for MIM, so it's not a file I would recommend anyone else to use. FIX.COM - This is a script for VMS systems using phase IV. FIX.PHV - This is a script for VMS systems using phase V. FIX.IMP - This is a script for VMS for anyone using DECdns. FIX.T20 - This is a script for TOPS-20. HECNET.PY - This is a definition file for PyDECnet. FIX.RST - This is a script for RSTS/E. NODENAMES.DAT - This is basically just the basic information is a simple output form from DATATRIEVE. It exist mostly for historical reasons, but I understand that lots of people actually take this file, and then write code to process, extract and apply information from this file. In addition, some systems can directly import nodenames from another machine on DECnet, meaning you do not have to fetch and run any scripts at all. So here is the actioins you need to do on each system in a summarized form: RSX: In RSX, there is a tool called NNC which copies definitions from another node. Copy over MIM::HECNET:NNC.BAT which is a batch file you can use which does all the work of importing the latest definitions from MIM and updating your local system. All you need to do is just "SUBMIT NNC.BAT" and you are done. VMS: With phase IV, the node copy capability is build into NCP. All you need to do is: "NCP COPY KNOWN NODES FROM MIM TO BOTH" and you are done. With phase V, copy over FIX.PHV and run it, or just directly run it from MIM like this: "@MIM::HECNET:FIX.PHV" If you run DECdns, grab FIX.IMP, and run it with whatever tool is used to manage this (sorry that I can't help more, I don't really have any experience with DECdns). TOPS-20: Grab MIM::HECNET:FIX.T20 and run in in the NCP submode of OPR (if I remember the setup correctly). RSTS/E: Grab MIM::HECNET:FIX.RST, and run it with "@FIX.RST". PyDECnet: Fetch hecnet.py by doing "wget mim.stupi.net/hecnet.py". Place that where you have configured PyDECnet to get the nodenames from, and you are good (not sure if you need to restart PyDECnet). Now. If you have some other system with some specific format you need, just let me know, and I'll create such a file as well. It's trivial for me to do this from DATATRIEVE. If you spot something wrong/bad in some file created today, let me know, and we'll fix it. If you see any errors or omissions in the information in this mail, let me know, and I'll get it corrected. I will create a web page with this information as well. If you want to get a mail whenever the nodename database is updated, just let me know and I'll add you to the list. And HECnet is slowly growing. Occasionally a completely new person/site gets connected. Occasionally people add more nodes. The online presence seems pretty constant. At the moment 19 areas are online. In area 1, currently there are 19 machines online. Looking at Paul's HECnet map (http://akdesign.dyndns.org:8080/map), there are machines online in quite different locations, covering a large part of the world. I find this cool, and even though there isn't a lot being done, it's still fun. Well. Have a nice weekend everyone, and I hope some people find this information useful. 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

10 months, 2 weeks

Re: [simh] OpenSIMH Networking Support on the MacOS

by Paul Koning

(resending with the correct HECnet address) > On Jul 25, 2024, at 12:16 AM, Chris Hanson <cmhanson(a)eschatologist.net> wrote: > > I haven’t successfully used SIMH networking on macOS yet but one of the things that I’ve seen in building SIMH with an Xcode project that I created was that there is *a lot* of type confusion in the codebase nowadays: It has lots of use of int, int32, etc. that should actually be one of ptrdiff_t, ssize_t, size_t, off_t, and so on. > > While I appreciate the desire to be compatible with older C89 compilers, this is one of those things that opens one up to subtle bugs on 64-bit platforms—especially when trying to build for a mix of LP64 and ILP64 platforms. I think the better way to handle that would be to provide cover definitions for pre-C99 compilers and pre/non-POSIX systems, so the codebase can use the correct types throughout. I suppose, but Mark P has a point: it doesn't make a whole lot of sense to do major editing on the codebase if it isn't broken. Clearly, ptrdiff and ssize are not issues, because nothing in the SIMH suite creates data structures that are more than 32 bits in size. If we had Alpha emulation for machines that support more than 4 GB of physical memory (if there are any Alphas for which that is true) then for that case the use of size_t would matter, but clearly not for anything else. Off_t is unlikely to be an issue either, unless you needed a virtual disk bigger than 4 GB. Those might, just barely, be supported on VAX (MSCP) and maybe some PDP-11 OS as well, though I know for a fact that RSTS/E tops out right at 4 GB and probably never actually had real disks that big. > Another pretty serious problem is that a lot of platforms set USE_SHARED rather than just USE_NETWORK and wind up “wrapping” the libpcap API, loading the library with dlopen(3) and calling through stubs that have their own prototypes defined. This is extremely dangerous because something like libpcap can adjust its signatures and headers simultaneously to manage source and binary compatibility while changing behavior at the same time. This is especially important when something like libpcap is provided by the OS. Um, the dlopen stuff seems to be an option, and it's only there on Linux as far as I can tell. Is it actually a problem? I'm not sure why it's there, I'll admit that. > ... > Similarly, the conflation of the various different integer types risks becoming a field full of land mines. While one can argue that SIMH is never dealing with enough data to run into 32-bit truncation on 64-bit systems so it’s not worth worrying about, this is another area where “it works fine, don’t change it” is just fine right up until the point where it isn’t. It’d be best to be consistent with POSIX here (rather than self-consistent) and to provide a thin adapter layer for pre-POSIX systems. It does seem that you're hypothesizing possible breakage but I don't see any way that it can happen in reality. Remember that SIMH works on 32 bit systems. It follows that the 32-bit types should not be a problem even if new code would not do it that way. paul

1 year, 1 month

FINGER survey...

by Johnny Billquist

I've been busy with my silly things as usual, and lately implemented a FINGER client and server for RSX, and I realized there are a couple of things to maybe check with other people on HECnet. First of all - finger as such is a (sortof) well known tool/service on the TCP/IP internet. And I've had a finger server and client for TCP/IP under RSX for a long time, but have never really shared it, since it was a bit "odd". But even before this, I knew of a FINGER implementation available from DECUS for RSX. I've known that I wanted to make FINGER available for others for a long time, but recently I started thinking of also adding in DECnet capability in my finger implementation. So the last few weeks I've been tinkering with this, and I've finally completed the work and made my new finger implementation available as a package. The FINGER from DECUS mentions the following: FINGER is a utility to display information about a selected user or group of users. It can be invoked for users on the local node or on a remote node over DECnet, and is com- patible with the VMS implimentation of FINGER. Full function- ality requires an RSX-11M+ system with resource accounting and DECnet. So, not only have there been this RSX implementation from DECUS, there apparently also exist(ed) an implementation from somewhere for VMS. FINGER over TCP uses the well known TCP port 79, while the DECUS RSX (and I assume VMS) DECnet implementation uses object number 117. My implementation then responds to both these access paths, as well as being able to query locally, and also try to connect to remote systems using either of these methods. And I now have this running on MIM:: So my questions are: . Do anyone else have any finger service running on any HECnet node? . Do anyone else know what other implementations even exist, and for which OSes? I do think FINGER is somewhat useful to find who might be logged in and active, as well as finding out more information about people on different systems in general. On the internet, finger servers are nowadays unusual to see, since privacy and security concerned people just feel that finger gives out way too much information anonymously. So I am not encouraging people to run this if they have such concerns. But like I said, personally, I do find it useful, and will keep it available on any RSX system that I am running. 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, 1 month

Tops-20 Kermit Version 5.3(255)-5 Maintenance Release Announcement

by Thomas DeBellis

Version 5.3(255)-5 incorporates additional features, enhancements and fixes since the minor release of 5.3(248)-5 in November 2023. These are as follows and can be identified in the code with the edit number as the prefix of a comment. [249] Implement relative directory connect [251] Emit new directory name when either wildcarded structure or directory changes [252] Fix some of the directory parsing logic to properly handle .CMDEV and .CMDIR [253] Fix ^A to print the number of pages sent and the total; was always omitting total [254] Implement CDUP, generic 'G' [255] Make CWD accept ".." as token for Unix, DOS, Windows, and OS/2 CDUP The changes were mainly driven to simulator relative directory connection as Tops-20 directory punctuation (I.E., '<' and '>') can too easily be confused with piping requests on some Kermit clients. On some, it proved impossible to convince them otherwise... Generic 'G' is an addition to the Kermit protocol. C-Kermit currently implements this in addition to Tops-20 Available for ANONYMOUS NFT from VENTI2:: and from https://www.kermitproject.org/kermit-20.html.

1 year, 1 month

Re: hii guys..tops20 expert needed

by Anders Andersson

"merlyn drforbin" <kropotkin(a)gmx.com> wrote: >Any way to set endpoint buffer size on panda decnet phase IV Could some of this (in SYSTEM:7-CONFIG.CMD) be what you are looking for? This is from RARITY (not PANDA, but DEC vanilla distribution,kind of), I'm not sure I have the correct values myself, been experimenting. ; DECnet parameters: ;default is DECNET BUFFER-SIZE 576 decnet buffer-size 1476 ;default is DECNET MAXIMUM-BUFFERS 80 ;decnet maximum-buffers 40 -- Anders Andersson, Uppsala, Sweden

1 year, 1 month

PyDECnet V1.1.0 released

by Paul Koning

Gentlepeople, The regular release of V1.1.0 is now published. You can download it from http://akdesign.dyndns.org:8080/resources/public/index.html . The code in Github is up to date, and the "main" branch has been updated to the V1.1.0 code. The "t1.1" branch is now retired. For those of you who have used the beta and/or release candidate releases: nothing much changed since then apart from bugfixes. If you're upgrading from V1.0, please be sure to read the documentation, in particular the CHANGES.txt file. A notable change that may affect your configuration files: f. The --api and --insecure-api switches on the "http" configuration line have been removed. Instead, API control is via a new "api" line. See doc/config.txt for details. paul

1 year, 1 month

hii guys..tops20 expert needed

by merlyn drforbin

Any way to set endpoint buffer size on panda decnet phase IV

1 year, 1 month

tops10 decnet

by merlyn drforbin

Hey guys. just got tops10 7.03 kinda working on hecnet. I'm still not able to set host to rsts and communication to from the node is spotty! Any suggests. Thank you in advance

1 year, 1 month

PyDECnet release candidate 2

by Paul Koning

I just released PyDECnet 1.1 rc2. You can find kits at http://akdesign.dyndns.org:8080/resources/public/index.html (the "V1.1 release candidate 2" lines are it). This contains a few bugfixes; a notable one makes HTTPS for the embedded web server work if you're running Python 3.12 or later. (Thanks Wilm!) I did a major rewrite of the "api-connecors.txt" documentation file, so now the recommended "Connectors" mechanism for writing PyDECnet applications and accessing its API should be a lot more useable. Barring surprises I'll probably issue the final V1.1 release in a week or so. paul

1 year, 1 month

auto launching pydecnet at boot?

by Mike Kostersitz

I am running my pydecnet router on a Raspberry Pi Zero W2 After switching to the beta/preview version the daemon does not start automatically when the Pi boots Do I need to make additional changes to enable that again? I don't remember from setting up the stable version anymore. Mike

1 year, 1 month

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet July 2024