Testing has been delayed for the LAVc configuration until this weekend -
work has a habit of getting in the way of hobbies.
In my version, I continue to use the same bridge.conf file except that I
have added the following:
[mop]
[sca]
[last]
I did not want to force MOP or LAT on a site that only needed one of
them so I split them out. This version has only one file with the
appropriate sites/areas included or commented out to keep things
cleaner/easier. Current testing is with two other sites. One is in the
US via the Internet, the other is here (multiple static IP addresses are
a wonderful thing).
I would be interested to see what may be the differences in my version
and the one you are using.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of gerry77 at mail.com
Sent: Thursday, December 03, 2009 16:38
To: hecnet at Update.UU.SE
Subject: [HECnet] Others DECnets (was: Boot VAX from Alpha host
Infoserver?)
On Sun, 29 Nov 2009 14:56:39 -0500, you wrote:
My version splits out LAT from MOP, adds SCA (LAVc) and LAST
(InfoServer). The LAT/MOP split has been verified to work. LAVc
support is being tested now. The LAST support testing is pending.
I'll take advantage of this message to say that here in this mailing
list
I'm a little bit like an impostor, because in truth I'm not a member of
HECnet, but of another Hobbyist DECnet based in Italy. :-P
We are now running a quite modified version of Johnny's bridge: we
departed
from his project because some of us have connection and bandwidth issues
that prevent the development of a strictly star-topology network as
required
by the HECnet bridge. We started experimenting many years ago (in the
2002-2004 timeframe) with Multinet and TCPware tunnels but were not
happy
with that solution because many of us had (and some still have) dynamic
IP
addresses which forced a tunnel recofiguration at every address change!
At the time, we already did know about HECnet but not about the bridge,
either because it didn't yet exist or because it was still unpublished,
so
we were forced to abandon out dreams of a DECnet of ours.
About three years ago, in the first days of december 2006, we learnt
about
the bridge and started again our experiments, but we soon understood
that we
were in need of some changes (among other things we had some nasty
packet
loops in the first days), so we asked to Johnny the permission to modify
his
work and here we go: our network is nominally made up of about 30 nodes,
all
in the same area, but only three to four are online 24/7, and has a full
mesh topology, that is every bridge is connected to every other bridge
(but
we later added a feature that allows for mixed topology networks).
If someone is interested in the full feature list and other details,
such as
some DECnet tuning we needed, s/he can contact me off list. :-)
Going back to the original topic, we choose to keep LAT and MOP
together,
and added LAST to the same group of protocols (but we renamed the .conf
section from [lat] to [lan]). Instead, we didn't ever consider
transporting
SCA across the Internet because it's too much a time-sensitive protocol
and
would be probably almost useless, at least here. Did you succeeded,
Steve,
in keeping on quorum a cluster across the bridge and the Internet?
Cheers,
G.
So, when are you finally going to join HECnet? :-)
Johnny
gerry77 at mail.com wrote:
On Sun, 29 Nov 2009 14:56:39 -0500, you wrote:
My version splits out LAT from MOP, adds SCA (LAVc) and LAST
(InfoServer). The LAT/MOP split has been verified to work. LAVc
support is being tested now. The LAST support testing is pending.
I'll take advantage of this message to say that here in this mailing list
I'm a little bit like an impostor, because in truth I'm not a member of
HECnet, but of another Hobbyist DECnet based in Italy. :-P
We are now running a quite modified version of Johnny's bridge: we departed
from his project because some of us have connection and bandwidth issues
that prevent the development of a strictly star-topology network as required
by the HECnet bridge. We started experimenting many years ago (in the
2002-2004 timeframe) with Multinet and TCPware tunnels but were not happy
with that solution because many of us had (and some still have) dynamic IP
addresses which forced a tunnel recofiguration at every address change!
At the time, we already did know about HECnet but not about the bridge,
either because it didn't yet exist or because it was still unpublished, so
we were forced to abandon out dreams of a DECnet of ours.
About three years ago, in the first days of december 2006, we learnt about
the bridge and started again our experiments, but we soon understood that we
were in need of some changes (among other things we had some nasty packet
loops in the first days), so we asked to Johnny the permission to modify his
work and here we go: our network is nominally made up of about 30 nodes, all
in the same area, but only three to four are online 24/7, and has a full
mesh topology, that is every bridge is connected to every other bridge (but
we later added a feature that allows for mixed topology networks).
If someone is interested in the full feature list and other details, such as
some DECnet tuning we needed, s/he can contact me off list. :-)
Going back to the original topic, we choose to keep LAT and MOP together,
and added LAST to the same group of protocols (but we renamed the .conf
section from [lat] to [lan]). Instead, we didn't ever consider transporting
SCA across the Internet because it's too much a time-sensitive protocol and
would be probably almost useless, at least here. Did you succeeded, Steve,
in keeping on quorum a cluster across the bridge and the Internet?
Cheers,
G.
--
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
RSX have taken another step that I don't know if you are aware of, Paul.
Yes, NCP is for the volatile database only. RSX then also have CFE,
which works pretty much the same way as NCP, but for the permanent
database. And as a third tool, there is VNP, which is odd in this sense,
since it affects parts of the DECnet operations, but on the image that
is booted (that is, you can perform a bunch of NCP commands on the
volatile database, but it's kind of "permanent" since it's done on a
file image that is booted, so in effect you are doing the NCP commands
before the system even boots).
However, RSX also moved the nodename database totally out of the main
DECned code, and have in fact a separate task that actually handles
nodename to number translations, called NNS.
So, both SCP and NCP as well as all tasks indirectly talks with NNS
whenever a nodename is given.
NCP under RSX (and CFE and VNP) furthermore don't have a COPY command.
But in connection with NNS is also a task called NNC, which can be used
to pull node names from another node into the nodename database used by
NNS. So that do the same thing as COPY in VMS (and some more stuff).
I suspect that one reason NCP and CFE was two different tasks in RSX was
probably for resource reasons. It was probably difficult to combine them
into one program for small RSX systems.
Johnny
Paul Koning wrote:
Ditto for the other DECnets. "COPY KNOWN NODES" is a VMS-specific
extension.
RSX is a particularly odd case, with its separate utility for handling
volatile vs. non-volatile stuff. That's not what the architecture
called for. DECnet/VMS and DECnet/E are much closer to standard. Not
that the network management spec was ever a complete standard; it was
inevitable that every OS would need OS-specific extensions, the question
was only how closely the final result would resemble what the spec talks
about.
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: Thursday, December 03, 2009 4:03 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] DECnet area router configuration
Well, the procedure in RSX is totally different anyway, so that's no
help. RSX have a totally separate task to handle node name stuff.
And NCP is only used for the volatile database.
Johnny
Steve Davidson wrote:
You need to use the "with purge" option for this to happen - at
least
in
VMS anyway.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On
Behalf Of Johnny Billquist
Sent: Thursday, December 03, 2009 15:21
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] DECnet area router configuration
Actually, I'm not entirely sure (I don't use VMS much nowadays), but
I
think it might remove all previous definitions before doing the
copy.
But that is easy to test. Just add a definition for some odd node
that
don't exist, and then do a copy.
Johnny
Ian McLaughlin wrote:
Does a COPY KNOWN NODES FROM xxx remove nodes in your local
database
that aren't listed any more?
It's fairly easy to run a COPY KNOWN NODES command once in a while.
I
guess the only piece missing is an automated way for MIM to get
updates
from everyone else.
Ian.
On 2009-12-03, at 12:10 PM, Sampsa Laine wrote:
The only (and this is a very minor) benefit that I can see in a
distributed naming system is that this way each owner of say an
area
could update the name database for his network and have it
automagically propagate, rather than a centralised system we have
right now which requires your time to keep up to date.
But it's not really that big a benefit to warrant the effort -
just
automate the periodic copying of the database from MIM would be my
suggestion as well...
Sampsa
On 3 Dec 2009, at 20:07, Johnny Billquist wrote:
Sridhar Ayengar wrote:
Johnny Billquist wrote:
Node list don't even get transmitted within the same area.
Node names are local to each machine, and it is perfectly valid
to
have
different names for the same node number on different machines
(although
perhaps confusing).
How hard would it be to write software as equivalent to DNS?
Not
necessarily for general-purpose use, but just for HECnet?
For what? Just copying the nodename database between machines?
The
software can already do that, so it would just be a question of
automating it a bit.
If you'd like to get a name lookup done from some central place
at
each
nodename lookup would be almost impossible. You'd need the source
code
for DECnet, and the ability to recompile it for that to be
possible.
Not
likely, I'm afraid.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se <mailto:bqt at softjar.se> ||
Reading
murder books
pdp is alive! || tryin' to stay hip" - B.
Idol
---
Filter service subscribers can train this email as spam or
not-spam
here:
http://my.email-as.net/spamham/cgi-
bin/learn.pl?messageid=E4AFF6EEE04711
DE98D9899E93ED0201
--
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
--
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 Sun, 29 Nov 2009 14:56:39 -0500, you wrote:
My version splits out LAT from MOP, adds SCA (LAVc) and LAST
(InfoServer). The LAT/MOP split has been verified to work. LAVc
support is being tested now. The LAST support testing is pending.
I'll take advantage of this message to say that here in this mailing list
I'm a little bit like an impostor, because in truth I'm not a member of
HECnet, but of another Hobbyist DECnet based in Italy. :-P
We are now running a quite modified version of Johnny's bridge: we departed
from his project because some of us have connection and bandwidth issues
that prevent the development of a strictly star-topology network as required
by the HECnet bridge. We started experimenting many years ago (in the
2002-2004 timeframe) with Multinet and TCPware tunnels but were not happy
with that solution because many of us had (and some still have) dynamic IP
addresses which forced a tunnel recofiguration at every address change!
At the time, we already did know about HECnet but not about the bridge,
either because it didn't yet exist or because it was still unpublished, so
we were forced to abandon out dreams of a DECnet of ours.
About three years ago, in the first days of december 2006, we learnt about
the bridge and started again our experiments, but we soon understood that we
were in need of some changes (among other things we had some nasty packet
loops in the first days), so we asked to Johnny the permission to modify his
work and here we go: our network is nominally made up of about 30 nodes, all
in the same area, but only three to four are online 24/7, and has a full
mesh topology, that is every bridge is connected to every other bridge (but
we later added a feature that allows for mixed topology networks).
If someone is interested in the full feature list and other details, such as
some DECnet tuning we needed, s/he can contact me off list. :-)
Going back to the original topic, we choose to keep LAT and MOP together,
and added LAST to the same group of protocols (but we renamed the .conf
section from [lat] to [lan]). Instead, we didn't ever consider transporting
SCA across the Internet because it's too much a time-sensitive protocol and
would be probably almost useless, at least here. Did you succeeded, Steve,
in keeping on quorum a cluster across the bridge and the Internet?
Cheers,
G.
Ditto for the other DECnets. "COPY KNOWN NODES" is a VMS-specific
extension.
RSX is a particularly odd case, with its separate utility for handling
volatile vs. non-volatile stuff. That's not what the architecture
called for. DECnet/VMS and DECnet/E are much closer to standard. Not
that the network management spec was ever a complete standard; it was
inevitable that every OS would need OS-specific extensions, the question
was only how closely the final result would resemble what the spec talks
about.
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: Thursday, December 03, 2009 4:03 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] DECnet area router configuration
Well, the procedure in RSX is totally different anyway, so that's no
help. RSX have a totally separate task to handle node name stuff.
And NCP is only used for the volatile database.
Johnny
Steve Davidson wrote:
You need to use the "with purge" option for this to happen - at
least
in
VMS anyway.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On
Behalf Of Johnny Billquist
Sent: Thursday, December 03, 2009 15:21
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] DECnet area router configuration
Actually, I'm not entirely sure (I don't use VMS much nowadays), but
I
think it might remove all previous definitions before doing the
copy.
But that is easy to test. Just add a definition for some odd node
that
don't exist, and then do a copy.
Johnny
Ian McLaughlin wrote:
Does a COPY KNOWN NODES FROM xxx remove nodes in your local
database
that aren't listed any more?
It's fairly easy to run a COPY KNOWN NODES command once in a while.
I
guess the only piece missing is an automated way for MIM to get
updates
from everyone else.
Ian.
On 2009-12-03, at 12:10 PM, Sampsa Laine wrote:
The only (and this is a very minor) benefit that I can see in a
distributed naming system is that this way each owner of say an
area
could update the name database for his network and have it
automagically propagate, rather than a centralised system we have
right now which requires your time to keep up to date.
But it's not really that big a benefit to warrant the effort -
just
automate the periodic copying of the database from MIM would be my
suggestion as well...
Sampsa
On 3 Dec 2009, at 20:07, Johnny Billquist wrote:
Sridhar Ayengar wrote:
Johnny Billquist wrote:
Node list don't even get transmitted within the same area.
Node names are local to each machine, and it is perfectly valid
to
have
different names for the same node number on different machines
(although
perhaps confusing).
How hard would it be to write software as equivalent to DNS?
Not
necessarily for general-purpose use, but just for HECnet?
For what? Just copying the nodename database between machines?
The
software can already do that, so it would just be a question of
automating it a bit.
If you'd like to get a name lookup done from some central place
at
each
nodename lookup would be almost impossible. You'd need the source
code
for DECnet, and the ability to recompile it for that to be
possible.
Not
likely, I'm afraid.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se <mailto:bqt at softjar.se> ||
Reading
murder books
pdp is alive! || tryin' to stay hip" - B.
Idol
---
Filter service subscribers can train this email as spam or
not-spam
here:
http://my.email-as.net/spamham/cgi-
bin/learn.pl?messageid=E4AFF6EEE04711
DE98D9899E93ED0201
--
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
Well, the procedure in RSX is totally different anyway, so that's no
help. RSX have a totally separate task to handle node name stuff.
And NCP is only used for the volatile database.
Johnny
Steve Davidson wrote:
You need to use the "with purge" option for this to happen - at least in
VMS anyway.
-Steve -----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: Thursday, December 03, 2009 15:21
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] DECnet area router configuration
Actually, I'm not entirely sure (I don't use VMS much nowadays), but I think it might remove all previous definitions before doing the copy.
But that is easy to test. Just add a definition for some odd node that don't exist, and then do a copy.
Johnny
Ian McLaughlin wrote:
Does a COPY KNOWN NODES FROM xxx remove nodes in your local database that aren't listed any more?
It's fairly easy to run a COPY KNOWN NODES command once in a while. I
guess the only piece missing is an automated way for MIM to get
updates
from everyone else.
Ian.
On 2009-12-03, at 12:10 PM, Sampsa Laine wrote:
The only (and this is a very minor) benefit that I can see in a distributed naming system is that this way each owner of say an area could update the name database for his network and have it automagically propagate, rather than a centralised system we have right now which requires your time to keep up to date.
But it's not really that big a benefit to warrant the effort - just automate the periodic copying of the database from MIM would be my suggestion as well...
Sampsa
On 3 Dec 2009, at 20:07, Johnny Billquist wrote:
Sridhar Ayengar wrote:
Johnny Billquist wrote:
Node list don't even get transmitted within the same area.
Node names are local to each machine, and it is perfectly valid to
have
different names for the same node number on different machines (although
perhaps confusing).
How hard would it be to write software as equivalent to DNS? Not necessarily for general-purpose use, but just for HECnet?
For what? Just copying the nodename database between machines? The
software can already do that, so it would just be a question of
automating it a bit.
If you'd like to get a name lookup done from some central place at
each
nodename lookup would be almost impossible. You'd need the source
code
for DECnet, and the ability to recompile it for that to be possible.
Not
likely, I'm afraid.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se <mailto:bqt at softjar.se> ||
Reading
murder books
pdp is alive! || tryin' to stay hip" - B. Idol
---
Filter service subscribers can train this email as spam or not-spam here:
http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=E4AFF6EEE04711
DE98D9899E93ED0201
--
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 Thu, 3 Dec 2009 12:14:32 -0800, you wrote:
Does a COPY KNOWN NODES FROM xxx remove nodes in your local database that
aren't listed any more?
Just add WITH PURGE at the end! :-)
G.
Actually, I'm not entirely sure (I don't use VMS much nowadays), but I think it might remove all previous definitions before doing the copy.
But that is easy to test. Just add a definition for some odd node that don't exist, and then do a copy.
Johnny
Ian McLaughlin wrote:
Does a COPY KNOWN NODES FROM xxx remove nodes in your local database that aren't listed any more?
It's fairly easy to run a COPY KNOWN NODES command once in a while. I guess the only piece missing is an automated way for MIM to get updates from everyone else.
Ian.
On 2009-12-03, at 12:10 PM, Sampsa Laine wrote:
The only (and this is a very minor) benefit that I can see in a distributed naming system is that this way each owner of say an area could update the name database for his network and have it automagically propagate, rather than a centralised system we have right now which requires your time to keep up to date.
But it's not really that big a benefit to warrant the effort - just automate the periodic copying of the database from MIM would be my suggestion as well...
Sampsa
On 3 Dec 2009, at 20:07, Johnny Billquist wrote:
Sridhar Ayengar wrote:
Johnny Billquist wrote:
Node list don't even get transmitted within the same area.
Node names are local to each machine, and it is perfectly valid to have
different names for the same node number on different machines (although
perhaps confusing).
How hard would it be to write software as equivalent to DNS? Not necessarily for general-purpose use, but just for HECnet?
For what? Just copying the nodename database between machines? The
software can already do that, so it would just be a question of
automating it a bit.
If you'd like to get a name lookup done from some central place at each
nodename lookup would be almost impossible. You'd need the source code
for DECnet, and the ability to recompile it for that to be possible. Not
likely, I'm afraid.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se <mailto:bqt at softjar.se> || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
---
Filter service subscribers can train this email as spam or not-spam here: http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=E4AFF6EEE04711DE9…
--
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
You need to use the "with purge" option for this to happen - at least in
VMS anyway.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: Thursday, December 03, 2009 15:21
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] DECnet area router configuration
Actually, I'm not entirely sure (I don't use VMS much nowadays), but I
think it might remove all previous definitions before doing the copy.
But that is easy to test. Just add a definition for some odd node that
don't exist, and then do a copy.
Johnny
Ian McLaughlin wrote:
Does a COPY KNOWN NODES FROM xxx remove nodes in your local database
that aren't listed any more?
It's fairly easy to run a COPY KNOWN NODES command once in a while. I
guess the only piece missing is an automated way for MIM to get
updates
from everyone else.
Ian.
On 2009-12-03, at 12:10 PM, Sampsa Laine wrote:
The only (and this is a very minor) benefit that I can see in a
distributed naming system is that this way each owner of say an area
could update the name database for his network and have it
automagically propagate, rather than a centralised system we have
right now which requires your time to keep up to date.
But it's not really that big a benefit to warrant the effort - just
automate the periodic copying of the database from MIM would be my
suggestion as well...
Sampsa
On 3 Dec 2009, at 20:07, Johnny Billquist wrote:
Sridhar Ayengar wrote:
Johnny Billquist wrote:
Node list don't even get transmitted within the same area.
Node names are local to each machine, and it is perfectly valid to
have
different names for the same node number on different machines
(although
perhaps confusing).
How hard would it be to write software as equivalent to DNS? Not
necessarily for general-purpose use, but just for HECnet?
For what? Just copying the nodename database between machines? The
software can already do that, so it would just be a question of
automating it a bit.
If you'd like to get a name lookup done from some central place at
each
nodename lookup would be almost impossible. You'd need the source
code
for DECnet, and the ability to recompile it for that to be possible.
Not
likely, I'm afraid.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se <mailto:bqt at softjar.se> ||
Reading
murder books
pdp is alive! || tryin' to stay hip" - B. Idol
---
Filter service subscribers can train this email as spam or not-spam
here:
http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=E4AFF6EEE04711
DE98D9899E93ED0201
--
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
Oh, no doubt it would be nice to have a distributed name service, but DECnet phase IV simply don't have it.
And adding it means going into the DECnet code, which I suspect, most people don't have. So it basically can't be done.
Note that the API (atleast in RSX, but I'm pretty sure it's true for other systems as well) actuall use node names, and not node numbers. So it's not like you could add another layer at the application program, that would make a query, and then use that information for the calls that build the connection block.
The name translation to a node number all happens internally in the DECnet code.
Johnny
Sampsa Laine wrote:
The only (and this is a very minor) benefit that I can see in a distributed naming system is that this way each owner of say an area could update the name database for his network and have it automagically propagate, rather than a centralised system we have right now which requires your time to keep up to date.
But it's not really that big a benefit to warrant the effort - just automate the periodic copying of the database from MIM would be my suggestion as well...
Sampsa
On 3 Dec 2009, at 20:07, Johnny Billquist wrote:
Sridhar Ayengar wrote:
Johnny Billquist wrote:
Node list don't even get transmitted within the same area.
Node names are local to each machine, and it is perfectly valid to have
different names for the same node number on different machines (although
perhaps confusing).
How hard would it be to write software as equivalent to DNS? Not necessarily for general-purpose use, but just for HECnet?
For what? Just copying the nodename database between machines? The
software can already do that, so it would just be a question of
automating it a bit.
If you'd like to get a name lookup done from some central place at each
nodename lookup would be almost impossible. You'd need the source code
for DECnet, and the ability to recompile it for that to be possible. Not
likely, I'm afraid.
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
--
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
A simple batch job will take care of this. Include in the batch job a "resubmit" so that you do not have to remember to run the procedure in the future. You might do it monthly or maybe even weekly.
The other direction is a bit more work, but certainly possible. At this point Johnny has to ensure that no one creates a namespace collision by using the same node name twice.
-Steve
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Ian McLaughlin
Sent: Thursday, December 03, 2009 15:15
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] DECnet area router configuration
Does a COPY KNOWN NODES FROM xxx remove nodes in your local database that aren't listed any more?
It's fairly easy to run a COPY KNOWN NODES command once in a while. I guess the only piece missing is an automated way for MIM to get updates from everyone else.
Ian.
On 2009-12-03, at 12:10 PM, Sampsa Laine wrote:
The only (and this is a very minor) benefit that I can see in a distributed naming system is that this way each owner of say an area could update the name database for his network and have it automagically propagate, rather than a centralised system we have right now which requires your time to keep up to date.
But it's not really that big a benefit to warrant the effort - just automate the periodic copying of the database from MIM would be my suggestion as well...
Sampsa
On 3 Dec 2009, at 20:07, Johnny Billquist wrote:
Sridhar Ayengar wrote:
Johnny Billquist wrote:
Node list don't even get transmitted within the same area.
Node names are local to each machine, and it is perfectly valid to have
different names for the same node number on different machines (although
perhaps confusing).
How hard would it be to write software as equivalent to DNS? Not necessarily for general-purpose use, but just for HECnet?
For what? Just copying the nodename database between machines? The
software can already do that, so it would just be a question of
automating it a bit.
If you'd like to get a name lookup done from some central place at each
nodename lookup would be almost impossible. You'd need the source code
for DECnet, and the ability to recompile it for that to be possible. Not
likely, I'm afraid.
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
---
Filter service subscribers can train this email as spam or not-spam here: http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=E4AFF6EEE04711DE9…
Does a COPY KNOWN NODES FROM xxx remove nodes in your local database that aren't listed any more?
It's fairly easy to run a COPY KNOWN NODES command once in a while. I guess the only piece missing is an automated way for MIM to get updates from everyone else.
Ian.
On 2009-12-03, at 12:10 PM, Sampsa Laine wrote:
The only (and this is a very minor) benefit that I can see in a distributed naming system is that this way each owner of say an area could update the name database for his network and have it automagically propagate, rather than a centralised system we have right now which requires your time to keep up to date.
But it's not really that big a benefit to warrant the effort - just automate the periodic copying of the database from MIM would be my suggestion as well...
Sampsa
On 3 Dec 2009, at 20:07, Johnny Billquist wrote:
Sridhar Ayengar wrote:
Johnny Billquist wrote:
Node list don't even get transmitted within the same area.
Node names are local to each machine, and it is perfectly valid to have
different names for the same node number on different machines (although
perhaps confusing).
How hard would it be to write software as equivalent to DNS? Not necessarily for general-purpose use, but just for HECnet?
For what? Just copying the nodename database between machines? The
software can already do that, so it would just be a question of
automating it a bit.
If you'd like to get a name lookup done from some central place at each
nodename lookup would be almost impossible. You'd need the source code
for DECnet, and the ability to recompile it for that to be possible. Not
likely, I'm afraid.
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
---
Filter service subscribers can train this email as spam or not-spam here: http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=E4AFF6EEE04711DE9…
The only (and this is a very minor) benefit that I can see in a distributed naming system is that this way each owner of say an area could update the name database for his network and have it automagically propagate, rather than a centralised system we have right now which requires your time to keep up to date.
But it's not really that big a benefit to warrant the effort - just automate the periodic copying of the database from MIM would be my suggestion as well...
Sampsa
On 3 Dec 2009, at 20:07, Johnny Billquist wrote:
Sridhar Ayengar wrote:
Johnny Billquist wrote:
Node list don't even get transmitted within the same area.
Node names are local to each machine, and it is perfectly valid to have
different names for the same node number on different machines (although
perhaps confusing).
How hard would it be to write software as equivalent to DNS? Not necessarily for general-purpose use, but just for HECnet?
For what? Just copying the nodename database between machines? The
software can already do that, so it would just be a question of
automating it a bit.
If you'd like to get a name lookup done from some central place at each
nodename lookup would be almost impossible. You'd need the source code
for DECnet, and the ability to recompile it for that to be possible. Not
likely, I'm afraid.
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
Sridhar Ayengar wrote:
Johnny Billquist wrote:
Node list don't even get transmitted within the same area.
Node names are local to each machine, and it is perfectly valid to have
different names for the same node number on different machines (although
perhaps confusing).
How hard would it be to write software as equivalent to DNS? Not necessarily for general-purpose use, but just for HECnet?
For what? Just copying the nodename database between machines? The
software can already do that, so it would just be a question of
automating it a bit.
If you'd like to get a name lookup done from some central place at each
nodename lookup would be almost impossible. You'd need the source code
for DECnet, and the ability to recompile it for that to be possible. Not
likely, I'm afraid.
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
Kari Uusim ki wrote:
There is already DECdns in DECnet Phase V aka DECnet-Plus.
If you want to use it, you can just create the database and then
populate it e.g. from the MIM's nodelist.
But is there any similar method available for Phase IV?
Peace... Sridhar
Sridhar Ayengar wrote:
Johnny Billquist wrote:
Node list don't even get transmitted within the same area.
Node names are local to each machine, and it is perfectly valid to have
different names for the same node number on different machines (although
perhaps confusing).
How hard would it be to write software as equivalent to DNS? Not necessarily for general-purpose use, but just for HECnet?
Peace... Sridhar
.
There is already DECdns in DECnet Phase V aka DECnet-Plus.
If you want to use it, you can just create the database and then populate it e.g. from the MIM's nodelist.
Johnny Billquist wrote:
Node list don't even get transmitted within the same area.
Node names are local to each machine, and it is perfectly valid to have
different names for the same node number on different machines (although
perhaps confusing).
How hard would it be to write software as equivalent to DNS? Not necessarily for general-purpose use, but just for HECnet?
Peace... Sridhar
Yes, I would say that copying the nodename database from MIM is the
canonical way of having an updated and "correct" nodename database.
Correct is somewhat misleading perhaps, as their isn't anything
incorrect with whatever nodename database you want to use.
But for a "uniform" view of nodenames on HECnet, MIM is the source.
And for you VMS guys out there, you should get a copy by typing (and the
NCP prompt)
"COPY KNOWN NODES FROM MIM TO BOTH"
Johnny
Sampsa Laine wrote:
I periodically COPY KNOWN NODES FROM MIM on all my machines, I consider MIM to be the canonical host list. Not sure if this is correct but has worked for me so far.
Sampsa
On 3 Dec 2009, at 19:06, gerry77 at mail.com wrote:
On Thu, 3 Dec 2009 10:53:31 -0800, you wrote:
SHOW KNOWN AREAS is showing 9 areas, which is good. SHOW KNOWN NODES isn't
showing any new nodes though. And a TELL 1.400 SHOW KNOWN NODES isn't
showing my nodes yet. (I'm area 42 if you start seeing it in the node list).
I'd have to check the docs, but IIRC the node list doesn't get transmitted
to different areas. Area routers exchange among themselves infos about their
area reachability and answer yes or not to the reachability of any node
under their scope (i.e. in their area), but do not transfer the whole area
contents to other nodes.
To see new nodes in SHOW KNOWN NODES you'll have to do a COPY KNOWN NODES
from a node that already knows the nodes you are interested in, then you'll
see all the nodes on a reachable area marked as reachable (even if the
specific node is powered off).
But do not take for granted this whole theory. :-)
G.
Usual disclaimer: Excuse my English: it's not my native language.
--
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
Node list don't even get transmitted within the same area.
Node names are local to each machine, and it is perfectly valid to have
different names for the same node number on different machines (although
perhaps confusing).
All routers transmit a connectivity information packet to every other
node within the same area. All area routers also transmit an area
connectivity packet to other area routers.
But these are just with node numbers, there are no node names
transmitted in these.
So it's a two level hierarchy. End nodes knows where the closest level
one router is (must have direct connection to it). All area one routers
knows the exact layout of their own area, and knows the shortest path to
any node within the area. Level one routers also knows where the closest
level two (area) router is. Level two routers knows the exact layout of
all level two routers, and the shortest path to any other level two
router (and thus any area).
Obviously, this means that all level one routers in one area must be
connected to all other routers within that same area, by just passing
through other level one routers.
And all level two routers must be connected (directly) to all other
level two routers by just going through level two routers.
Johnny
gerry77 at mail.com wrote:
On Thu, 3 Dec 2009 10:53:31 -0800, you wrote:
SHOW KNOWN AREAS is showing 9 areas, which is good. SHOW KNOWN NODES isn't showing any new nodes though. And a TELL 1.400 SHOW KNOWN NODES isn't showing my nodes yet. (I'm area 42 if you start seeing it in the node list).
I'd have to check the docs, but IIRC the node list doesn't get transmitted
to different areas. Area routers exchange among themselves infos about their
area reachability and answer yes or not to the reachability of any node
under their scope (i.e. in their area), but do not transfer the whole area
contents to other nodes.
To see new nodes in SHOW KNOWN NODES you'll have to do a COPY KNOWN NODES
from a node that already knows the nodes you are interested in, then you'll
see all the nodes on a reachable area marked as reachable (even if the
specific node is powered off).
But do not take for granted this whole theory. :-)
G.
Usual disclaimer: Excuse my English: it's not my native language.
--
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
That would be expected when you haven't defined any nodenames for nodes
in area 42.
As a reminder to everyone. DECnet phase IV don't have any centralized
nodename database. Every machine has his own nodename database.
And you need to update it occasionally if you want to have any new nodes
appear in there.
Otherwise you might just see node numbers, without any node names
associated with them. And such nodes are not "known". :-)
Johnny
Sampsa Laine wrote:
Well GORVAX can see area 42 but no nodes in it..
CHIMPY$ ncp tell gorvax show known areas
Known Area Volatile Summary as of 3-DEC-2009 19:57:20
Area State Circuit Next node to area
1 reachable 1.400 (GORVAX)
2 reachable TCP-0-0 2.17 (CHARON)
3 reachable TCP-0-0 2.17 (CHARON)
11 reachable QNA-0 11.2 (MAISA)
19 reachable QNA-0 19.11 (AGENA)
42 reachable QNA-0 42.1
51 reachable TCP-0-0 2.17 (CHARON)
59 reachable TCP-0-0 2.17 (CHARON)
60 reachable QNA-0 60.664 (PDXVAX)
On 3 Dec 2009, at 18:53, Ian McLaughlin wrote:
On 2009-12-03, at 10:49 AM, gerry77 at mail.com <mailto:gerry77 at mail.com> wrote:
At the moment I cannot remember if @SYS$MANAGER:NETCONFIG.COM asks something
about configuring a node as an area router, but I'm assuming that it doesn't
ask anything, or you wouldn't be here asking for help. :-)
As a starting point you may just type the following:
$ RUN SYS$SYSTEM:NCP
NCP> SET EXECUTOR STATE SHUT
NCP> DEFINE EXECUTOR TYPE AREA
NCP> EXIT
$ @SYS$MANAGER:STARTNET
If I'm not wrong, this should be enough to transform your node into an area
router; then you may want to revise your configuration to tune it better.
You are correct - NETCONFIG doesn't ask about level 1 or 2 - just whether you're a router or not. Your commands (which I'm sure I tried some time during the last 24 hours, but I'm not sure) followed by a reboot seems to have fixed it. Thanks!
SHOW KNOWN AREAS is showing 9 areas, which is good. SHOW KNOWN NODES isn't showing any new nodes though. And a TELL 1.400 SHOW KNOWN NODES isn't showing my nodes yet. (I'm area 42 if you start seeing it in the node list).
At least there's some connectivity. I'll keep working. Thanks for the help.
Ian.
--
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
Ian McLaughlin wrote:
On 2009-12-03, at 10:49 AM, gerry77 at mail.com <mailto:gerry77 at mail.com> wrote:
At the moment I cannot remember if @SYS$MANAGER:NETCONFIG.COM asks something
about configuring a node as an area router, but I'm assuming that it doesn't
ask anything, or you wouldn't be here asking for help. :-)
As a starting point you may just type the following:
$ RUN SYS$SYSTEM:NCP
NCP> SET EXECUTOR STATE SHUT
NCP> DEFINE EXECUTOR TYPE AREA
NCP> EXIT
$ @SYS$MANAGER:STARTNET
If I'm not wrong, this should be enough to transform your node into an area
router; then you may want to revise your configuration to tune it better.
You are correct - NETCONFIG doesn't ask about level 1 or 2 - just whether you're a router or not. Your commands (which I'm sure I tried some time during the last 24 hours, but I'm not sure) followed by a reboot seems to have fixed it. Thanks!
SHOW KNOWN AREAS is showing 9 areas, which is good. SHOW KNOWN NODES isn't showing any new nodes though. And a TELL 1.400 SHOW KNOWN NODES isn't showing my nodes yet. (I'm area 42 if you start seeing it in the node list).
At least there's some connectivity. I'll keep working. Thanks for the help.
The show known nodes command of course depend on what you mean by known
nodes... :-)
(See more in my other replies...)
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
gerry77 at mail.com wrote:
On Thu, 3 Dec 2009 10:53:31 -0800, you wrote:
SHOW KNOWN AREAS is showing 9 areas, which is good. SHOW KNOWN NODES isn't showing any new nodes though. And a TELL 1.400 SHOW KNOWN NODES isn't showing my nodes yet. (I'm area 42 if you start seeing it in the node list).
I'd have to check the docs, but IIRC the node list doesn't get transmitted
to different areas. Area routers exchange among themselves infos about their
area reachability and answer yes or not to the reachability of any node
under their scope (i.e. in their area), but do not transfer the whole area
contents to other nodes.
To see new nodes in SHOW KNOWN NODES you'll have to do a COPY KNOWN NODES
from a node that already knows the nodes you are interested in, then you'll
see all the nodes on a reachable area marked as reachable (even if the
specific node is powered off).
But do not take for granted this whole theory. :-)
G.
Usual disclaimer: Excuse my English: it's not my native language.
.
The DECnet routing works just as Gerry told.
Area routers exchange area information among themselves by sending router hello's. Endnodes inform the area routers about their existence by sending endnode hello's and L1 and L2 routers send router hello's which also the endnodes listen to.
All the routing information is sent by multicasting.
So all nodes learn the needed information from the network without any operator efforts.
That is true if the network is configured by the rules. :)
Kari
gerry77 at mail.com wrote:
On Thu, 3 Dec 2009 10:16:27 -0800, you wrote:
with DECnet Phase IV installed. I've been going through every document I can find, but I can't find anything that talks about setting up a level 2 (area) router. What do I have to do different from a normal (level 1) router? I'd appreciate any pointers. Let me know if you'd like to see any diagnostic output.
At the moment I cannot remember if @SYS$MANAGER:NETCONFIG.COM asks something
about configuring a node as an area router, but I'm assuming that it doesn't
ask anything, or you wouldn't be here asking for help. :-)
As a starting point you may just type the following:
$ RUN SYS$SYSTEM:NCP
NCP> SET EXECUTOR STATE SHUT
NCP> DEFINE EXECUTOR TYPE AREA
NCP> EXIT
$ @SYS$MANAGER:STARTNET
If I'm not wrong, this should be enough to transform your node into an area
router; then you may want to revise your configuration to tune it better.
HTH, :-)
G.
.
Yes, quite so.
The NETCONFIG.COM asks only if you want to configure a router or end node. When it asks that you should answer that you want to run the node as a router, but before you start DECnet, you should do the DEFINE statement as in Gerry's message.
It takes some time before the router hello's and endnode hello's traverse the network, but after a while you should see the other areas from your Area router node and others should see your area.
Regards,
Kari
I periodically COPY KNOWN NODES FROM MIM on all my machines, I consider MIM to be the canonical host list. Not sure if this is correct but has worked for me so far.
Sampsa
On 3 Dec 2009, at 19:06, gerry77 at mail.com wrote:
On Thu, 3 Dec 2009 10:53:31 -0800, you wrote:
SHOW KNOWN AREAS is showing 9 areas, which is good. SHOW KNOWN NODES isn't
showing any new nodes though. And a TELL 1.400 SHOW KNOWN NODES isn't
showing my nodes yet. (I'm area 42 if you start seeing it in the node list).
I'd have to check the docs, but IIRC the node list doesn't get transmitted
to different areas. Area routers exchange among themselves infos about their
area reachability and answer yes or not to the reachability of any node
under their scope (i.e. in their area), but do not transfer the whole area
contents to other nodes.
To see new nodes in SHOW KNOWN NODES you'll have to do a COPY KNOWN NODES
from a node that already knows the nodes you are interested in, then you'll
see all the nodes on a reachable area marked as reachable (even if the
specific node is powered off).
But do not take for granted this whole theory. :-)
G.
Usual disclaimer: Excuse my English: it's not my native language.
On Thu, 3 Dec 2009 10:53:31 -0800, you wrote:
SHOW KNOWN AREAS is showing 9 areas, which is good. SHOW KNOWN NODES isn't
showing any new nodes though. And a TELL 1.400 SHOW KNOWN NODES isn't
showing my nodes yet. (I'm area 42 if you start seeing it in the node list).
I'd have to check the docs, but IIRC the node list doesn't get transmitted
to different areas. Area routers exchange among themselves infos about their
area reachability and answer yes or not to the reachability of any node
under their scope (i.e. in their area), but do not transfer the whole area
contents to other nodes.
To see new nodes in SHOW KNOWN NODES you'll have to do a COPY KNOWN NODES
from a node that already knows the nodes you are interested in, then you'll
see all the nodes on a reachable area marked as reachable (even if the
specific node is powered off).
But do not take for granted this whole theory. :-)
G.
Usual disclaimer: Excuse my English: it's not my native language.