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
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
Gentlepeople,
I figured it was about time to move PyDECnet past the "beta 1.1" stage. I sorted through the various bugfixes I had not yet commmitted and did so, the built kits called "release candidate 1". The code is currently running on node PYTHON, and kits can be found on the downloads page at http://akdesign.dyndns.org:8080/resources/public/index.html
I'd like to get the "real" release out soon, so it would be great if some of you could take this version for a test drive. I'd also like to hear if there were any bugfixes I was supposed to do that I missed.
By the way, this version requires Python 3.7 or later.
Last but not least, I moved the source control to GitHub: https://github.com/pkoning2/pydecnet . The Subversion repository is now obsolete; I will take it off line soon. The full history should be in the Git version (it was converted from the Subversion repository).
paul
I was just reading about an alternate Python implementation called PyPy, which uses a "just in time" compiler. With that it's supposed to be potentially a lot faster than regular Python, for code that does a fair amount of computation.
While PyDECnet does plenty of I/O, things like packet parsing are fairly time consuming. I've optimized it a bit but the structure I adopted only allows for so much.
I tried PyPy to see if it supports PyDECnet. The answer is yes, after I removed some code from two files that wasn't even used in the first place...
Just to see if it makes a big difference, I did a large loop test: "ncp loop nod 0 count 50000 len 400". On my Mac (ARM) laptop, that takes 6.3 seconds with Python 3.13, and 1.2 seconds with PyPy.
More testing is needed but this is interesting.
paul
Hi,
I'm including this in HECnet because it might be of general interest.
I have been creating the odd object here and there on a test router, using the mirror.py application class as a starting example, for listening to and talking to VMS processes that have opened up a task connection to them.
I can do something like:
$ open/read/write fio node::"=TIMESTAMP"
$ write fio "UTC"
$ read fio ts
$ close fio
$ show sym fio
The object waits for a message - the timezone required - and then returns with a message containing the VMS time string in the form dd-mmm-yyyy:hh:mm:ss.cc
It all work very well.
The dispatch method in the pydecnet application class code sends an accept when it gets a connect and then sends a message containing the timestamp when it receives a data message containing the timezone required.
A simpler version of this, in which the timestamp in UTC is sent immediately without waiting for a timezone string, would not work. I was trying to execute a conn.send_data(...) immediately after a conn.accept() and getting a 'WrongState' exception there and then. What am I missing?
Regards
Keith
