9 Dec
2021
9 Dec
'21
8:09 a.m.
A little while ago, I got a second hecnet link to let me get on hecnet from my office at
my day job. I've moved some of my node names from my home in Riverside, CA to my
office in Norco, CA. If I wanted to get a new pin at http://akdesign.dyndns.org:8080/map
for my relocated nodes, do I need to pester somebody to manually update locations in a
database? Or does the mapping crawler look for something on the nodes which might feed
updated location information to it?
I've begun putting .BEGIN-HECNET-INFO blocks in my INFO.TXT files, plagiarizing what I
saw on Robert's nodes. But I get the impression that nothing automatically parses
those at this time?
It's kind of silly that my Riverside and Norco nodes are quite close to each other in
southern California, but have two separate links up to the bay area. I can't accept
incoming connections either at home or at work, so I have two separate links to Robert
instead of just linking directly between my two sites. Sigh. I'm still happy that I
can get on hecnet both from home and work, and my two sites can talk to each other.
Interactive sessions are naturally sluggish when I do something like editing a file, but
it seems to work quite well otherwise.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
https://www.nf6x.net/
9 Dec
9 Dec
12:55 p.m.
You have to pester me to get the position updated. Another thing that
would be nice to self-service in some way at some point... :-)
Johnny
On 2021-12-09 08:09, Mark J. Blair wrote:
A little while ago, I got a second hecnet link to let
me get on hecnet from my office at my day job. I've moved some of my node names from
my home in Riverside, CA to my office in Norco, CA. If I wanted to get a new pin at
http://akdesign.dyndns.org:8080/map for my relocated nodes, do I need to pester somebody
to manually update locations in a database? Or does the mapping crawler look for something
on the nodes which might feed updated location information to it?
I've begun putting .BEGIN-HECNET-INFO blocks in my INFO.TXT files, plagiarizing what
I saw on Robert's nodes. But I get the impression that nothing automatically parses
those at this time?
It's kind of silly that my Riverside and Norco nodes are quite close to each other in
southern California, but have two separate links up to the bay area. I can't accept
incoming connections either at home or at work, so I have two separate links to Robert
instead of just linking directly between my two sites. Sigh. I'm still happy that I
can get on hecnet both from home and work, and my two sites can talk to each other.
Interactive sessions are naturally sluggish when I do something like editing a file, but
it seems to work quite well otherwise.
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
5:45 p.m.
On Dec 9, 2021, at 3:55 AM, Johnny Billquist <bqt
at softjar.se> wrote:
You have to pester me to get the position updated. Another thing that would be nice to
self-service in some way at some point... :-)
Well, I don't want to pester you for that right in the middle of the whole Update
move. Has a new home for the mailing list been found? Maybe MAIL or NOTES over hecnet? :)
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
https://www.nf6x.net/
5:58 p.m.
Idea:
Put the lat/long of the node in the DECnet executor identification,
something like this.. (just an example)
set exECUTOR idENTIFICATION "DECnet-10 Version 4.0 *59.22222,18.88888*"
Then anyone can pull it with:
NCP>sh exec char
Executor Node = 59.1 (ODEN)
Identification = DECnet-10 Version 4.0 *59.22222,18.88888*
--P
6 p.m.
On Dec 9, 2021, at 8:58 AM, Peter Lothberg <roll at
stupi.com> wrote:
Idea:
Put the lat/long of the node in the DECnet executor identification,
something like this.. (just an example)
Interesting! I like it. I'd be happy to play along.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
https://www.nf6x.net/
7:06 p.m.
On Dec 9, 2021, at 11:58 AM, Peter Lothberg <roll
at stupi.com> wrote:
Idea:
Put the lat/long of the node in the DECnet executor identification,
something like this.. (just an example)
set exECUTOR idENTIFICATION "DECnet-10 Version 4.0 *59.22222,18.88888*"
Then anyone can pull it with:
NCP>sh exec char
Executor Node = 59.1 (ODEN)
Identification = DECnet-10 Version 4.0 *59.22222,18.88888*
Nice idea. A couple of limitations: the ident string max length is fairly low, though
some implementations ignore the specified limit. And this only works if the node is (a)
up and (b) allow NICE connections. While updating Johnny's database requires some
manual action, it has the benefit that it applies to any node, up or down, Cisco or
otherwise.
The mapper queries it once a day (the top line on the map display shows the most recent
"database update").
paul
7:23 p.m.
If you start with Johnnys database, and when you poll a node and get
an answer, you store the new value in the database.
Now the remaining problem is how to add the manual updates for nodes
that don't respond, and i would say, 'send the updates to Paul".
And I guess we could move the "auto updated" database to MIM at some
regular interval..
Just trying to automate things.
-P
----- Original Message -----
From: "Paul Koning" <paulkoning at
comcast.net>
To: "hecnet" <hecnet at Update.UU.SE>
Sent: Thursday, December 9, 2021 1:06:37 PM
Subject: Re: [HECnet] Updating Map Locations
Nice idea. A couple of limitations: the ident string
max length is fairly low,
though some implementations ignore the specified limit. And this only works if
the node is (a) up and (b) allow NICE connections. While updating Johnny's
database requires some manual action, it has the benefit that it applies to any
node, up or down, Cisco or otherwise.
The mapper queries it once a day (the top line on the map display shows the most
recent "database update").
paul
11:17 p.m.
On 2021-12-09 19:06, Paul Koning wrote:
I agree that while a nice idea, it have some limitations.
The string length is one. That you need to talk NICE is another. A third
is that you'd only get information from machines that are up.
There is also always the risk that you get inconsistencies on how the
information is actually stored on different nodes when pretty much
everyone have to do it themselves.
I won't mind if people do it, but I'm not going to stop having the
information in the nodename database as well. At some point, one could
write a scraper to somewhat automate things, but that's not at the top
of my list right now. The effort of maintaining the nodename database is
very low.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Dec 9, 2021, at 11:58 AM, Peter Lothberg
<roll at stupi.com> wrote:
Idea:
Put the lat/long of the node in the DECnet executor identification,
something like this.. (just an example)
set exECUTOR idENTIFICATION "DECnet-10 Version 4.0 *59.22222,18.88888*"
Then anyone can pull it with:
NCP>sh exec char
Executor Node = 59.1 (ODEN)
Identification = DECnet-10 Version 4.0 *59.22222,18.88888*
Nice idea. A couple of limitations: the ident string max length is fairly low, though
some implementations ignore the specified limit. And this only works if the node is (a)
up and (b) allow NICE connections. While updating Johnny's database requires some
manual action, it has the benefit that it applies to any node, up or down, Cisco or
otherwise.
The mapper queries it once a day (the top line on the map display shows the most recent
"database update"). 
8:39 p.m.
That's a nice hack.
Were we to have source to the various NICE executables, I would say that
the thing to do would be to a "location" field in addition to the
identification field.
Another thing would be a DECnet DNS, which is something that has been on
my list to do (enhance Chives)
On 12/9/21 11:58 AM, Peter Lothberg wrote:
Idea:
Put the lat/long of the node in the DECnet executor identification,
something like this.. (just an example)
set exECUTOR idENTIFICATION "DECnet-10 Version 4.0 *59.22222,18.88888*"
Then anyone can pull it with:
NCP>sh exec char
Executor Node = 59.1 (ODEN)
Identification = DECnet-10 Version 4.0 *59.22222,18.88888*
--P
8:52 p.m.
On Dec 9, 2021, at 2:39 PM, Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
That's a nice hack.
Were we to have source to the various NICE executables, I would say that the thing to do
would be to a "location" field in addition to the identification field.
That's easy enough in principle, the protocol is readily extensible. The difficulty
of course would be to extend the NCP and NML implementations to deliver that new
attribute.
Another thing would be a DECnet DNS, which is
something that has been on my list to do (enhance Chives)
DECdns is a standard Phase V feature. I have never used it but I remember participating
in the design of that specification; it's got a bunch of neat capabilities. Come to
think of it the DEC time service would also be interesting to have.
paul
11:22 p.m.
On 2021-12-09 20:52, Paul Koning wrote:
Yeah. And add the commands to be able to set the value, and somehow read
it out from another node. It's not enough with just defining the field,
or even just deliver it. And it's quite a job if you want to try and
update all different OSes that would need it.
The functionality would be nice, but I don't fancy phase V. :-)
And in Phase IV, while we could do it, you need to write software for
various OSes to make use of it. Maybe one day, but this seems another
one of those fun hacks, that maybe eventually will be partially done,
but will never be for everyone.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Dec 9, 2021, at 2:39 PM, Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
That's a nice hack.
Were we to have source to the various NICE executables, I would say that the thing to do
would be to a "location" field in addition to the identification field.
That's easy enough in principle, the protocol is readily extensible. The difficulty
of course would be to extend the NCP and NML implementations to deliver that new
attribute. Another thing
would be a DECnet DNS, which is something that has been on my list to do (enhance Chives)
DECdns is a standard Phase V feature. I have never used it but I remember participating
in the design of that specification; it's got a bunch of neat capabilities. Come to
think of it the DEC time service would also be interesting to have.
10 Dec
10 Dec
1:42 a.m.
On Dec 9, 2021, at 5:22 PM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2021-12-09 20:52, Paul Koning wrote:
Yeah. And add the commands to be able to set the value, and somehow read it out from
another node. It's not enough with just defining the field, or even just deliver it.
And it's quite a job if you want to try and update all different OSes that would need
it.
The functionality would be nice, but I don't fancy phase V. :-)
And in Phase IV, while we could do it, you need to write software for various OSes to
make use of it. Maybe one day, but this seems another one of those fun hacks, that maybe
eventually will be partially done, but will never be for everyone.
I don't know if the various applications developed as part of Phase V are inherently
limited to Phase V only. It may well be valid to use DECdns in Phase IV. Or DECdts.
paul
On Dec 9,
2021, at 2:39 PM, Thomas DeBellis <tommytimesharing at gmail.com> wrote:
That's a nice hack.
Were we to have source to the various NICE executables, I would say that the thing to do
would be to a "location" field in addition to the identification field.
That's easy enough in principle, the protocol is readily extensible. The difficulty
of course would be to extend the NCP and NML implementations to deliver that new
attribute. Another
thing would be a DECnet DNS, which is something that has been on my list to do (enhance
Chives)
DECdns is a standard Phase V feature. I have never used it but I remember
participating in the design of that specification; it's got a bunch of neat
capabilities. Come to think of it the DEC time service would also be interesting to have.
9 Dec
9 Dec
11:07 p.m.
Hi.
On 2021-12-09 17:45, Mark J. Blair wrote:
No worries. Send me updates and I'll apply when I have a little time.
It's usually not that difficult to do these updates. It sits in the
nodename database, which I then combine with a database for locations to
lat/lon mappings. If you log into MIM (or have an RSX system on which
you install the DDB tool), you can check the information yourself (or
use remote DTR to look at the info).
.ddb mim
(Using local interface)
Node: MIM
Address: 1.13
Owner: Johnny Billquist
OS: RSX-11M-PLUS V4.6
CPU: PDP-11/74 (e11)
Created: 12 Nov 2011 12:00:00
Modified: 21 Nov 2021 22:59:35
Loc: Reimersholme, Sweden
Coord: 59.317551,18.023352
.
Working on the mailing list problem. I should have something up and
running by tomorrow. I'll send out information about the move of the
list as soon as I have things working.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Dec 9, 2021, at 3:55 AM, Johnny Billquist
<bqt at softjar.se> wrote:
You have to pester me to get the position updated. Another thing that would be nice to
self-service in some way at some point... :-)
Well, I don't want to pester you for that right in the middle of the whole Update
move. Has a new home for the mailing list been found? Maybe MAIL or NOTES over hecnet? :)
1078
days inactive
1079
days old
12 comments
5 participants
participants (5)
-
bqt＠softjar.se -
nf6x＠nf6x.net -
paulkoning＠comcast.net -
roll＠stupi.com -
tommytimesharing＠gmail.com