I would like to claim area 52.
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
Paul,
The overhead incurred by level 1 or level 2 routing was pretty low. The site
I mentioned in the earlier example grew to more than 1000 pc's. They all ran
DECnet for Pathworks connectivity. They just fitted in one DECnet area. The
area routing was performed by two microVAX II systems, one active, the other
backup. They did nothing but area routing and had sufficient cpu power and
memory available. Ethernet was 10BASE2 in those days and that worked well.
The only traffic outside the area was CTERM and a little FAL.
The reason we didn't turn of console logging was that plant personnel
archived the console logs for reference purposes.
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Paul Koning
Verzonden: dinsdag, juni 2010 12:55
Aan: hecnet at Update.UU.SE
Onderwerp: RE: [HECnet] Attaching to hecnet
Johnny, the original DECnet manuals showed pictures of area routers
that
were interconnected by WAN links. Each site had its own area number.
In
fact
the name "area routing" implies clearly that the concept was meant to
set up
DECnet networks that were geographically separated.
I don't remember those pictures, but this is an issue that generated a
lot of debate and a lot of annoyance in the DECnet architecture group.
...
One reason for separating systems in different areas was that
rebooting
the
pc's would generate so many DECnet state up and down messages that
PDP-
11's
and the older VAX systems choked in their console output.
That's a good one. (Actually, the way to deal with that is to turn the
logging to console off for that event...) Yes, that's a valid example.
The purpose of area routing is to avoid having things get too large.
There were various opinions on how big an area (or Phase III network)
could reasonably be. Originally the limit was assumed to be about 32,
without any basis that I know of. That too produced a pile of debate,
and later on it became obvious you could go much higher. But clearly
you couldn't run a flat Phase III style network with 10,000 nodes.
For that reason area routing was introduced, so each instance of the
routing algorithm (in-area and level 2) would deal with a reasonably
small topology. Again debates broke out whether a full area (1000
nodes) was acceptable. It turned out yes, but certainly keeping it
smaller, say to 100-200, would be a good thing if possible.
Geography isn't a consideration unless the links are slow enough to make
route change propagation an issue. Corporate organization (different
departments) CERTAINLY isnt' a consideration, though some people tried
to argue that it was valid to do so.
paul
Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com
Versie: 9.0.830 / Virusdatabase: 271.1.1/2969 - datum van uitgifte: 06/28/10
20:35:00
On Tue, Jun 29, 2010 at 12:36:06PM -0400, Steve Davidson wrote:
Brian,
I have sent you a copy of the area list and the nodename list.
Fantastic, thanks Steve!!
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
On Mon, Jun 28, 2010 at 12:10:31PM -0700, Johnny Billquist wrote:
Should I just use one area? What's the best way to set that up?
Areas in DECnet are not really meant to be associated with physical
location, but rather with organizational. So keep it within one area.
Ok, sounds good to me.
For physically different locations, you might want to use level 1
routers, though. But as the internet nowadays is so fast, using just a
bridge, and pretend that it's all one ethernet segment also works just
fine.
My upstream blows (as well as latency in general) so I'd like to avoid
putting any more traffic across it than is absolutely nessesary.
I suppose it's not a huge deal at this point since the SIMH instance at
the colo will be the only thing running most likely for a little while.
That being said, how should I set it up? L1? L2? Does anyone want to
use me as a hub?
Also, is there a list of what areas are already in use so I can pick an
unused one?
Thanks!!
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
Brian,
I have sent you a copy of the area list and the nodename list.
-Steve
On Mon, Jun 28, 2010 at 12:10:31PM -0700, Johnny Billquist wrote:
Should I just use one area? What's the best way to set that up?
Areas in DECnet are not really meant to be associated with physical
location, but rather with organizational. So keep it within one area.
Ok, sounds good to me.
For physically different locations, you might want to use level 1
routers, though. But as the internet nowadays is so fast, using just a
bridge, and pretend that it's all one ethernet segment also works just
fine.
My upstream blows (as well as latency in general) so I'd like to avoid
putting any more traffic across it than is absolutely nessesary.
I suppose it's not a huge deal at this point since the SIMH instance at
the colo will be the only thing running most likely for a little while.
That being said, how should I set it up? L1? L2? Does anyone want to
use me as a hub?
Also, is there a list of what areas are already in use so I can pick an
unused one?
Thanks!!
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
The definitive list is maintained at MIM::US:[DECNET]DECNET.TXT. I'll send
you a copy outside of this list.
-Steve
On Mon, Jun 28, 2010 at 12:10:31PM -0700, Johnny Billquist wrote:
Should I just use one area? What's the best way to set that up?
Areas in DECnet are not really meant to be associated with physical
location, but rather with organizational. So keep it within one area.
Ok, sounds good to me.
For physically different locations, you might want to use level 1
routers, though. But as the internet nowadays is so fast, using just a
bridge, and pretend that it's all one ethernet segment also works just
fine.
My upstream blows (as well as latency in general) so I'd like to avoid
putting any more traffic across it than is absolutely nessesary.
I suppose it's not a huge deal at this point since the SIMH instance at
the colo will be the only thing running most likely for a little while.
That being said, how should I set it up? L1? L2? Does anyone want to
use me as a hub?
Also, is there a list of what areas are already in use so I can pick an
unused one?
Thanks!!
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
Johnny, the original DECnet manuals showed pictures of area routers
that
were interconnected by WAN links. Each site had its own area number.
In
fact
the name "area routing" implies clearly that the concept was meant to
set up
DECnet networks that were geographically separated.
I don't remember those pictures, but this is an issue that generated a
lot of debate and a lot of annoyance in the DECnet architecture group.
...
One reason for separating systems in different areas was that
rebooting
the
pc's would generate so many DECnet state up and down messages that
PDP-
11's
and the older VAX systems choked in their console output.
That's a good one. (Actually, the way to deal with that is to turn the
logging to console off for that event...) Yes, that's a valid example.
The purpose of area routing is to avoid having things get too large.
There were various opinions on how big an area (or Phase III network)
could reasonably be. Originally the limit was assumed to be about 32,
without any basis that I know of. That too produced a pile of debate,
and later on it became obvious you could go much higher. But clearly
you couldn't run a flat Phase III style network with 10,000 nodes.
For that reason area routing was introduced, so each instance of the
routing algorithm (in-area and level 2) would deal with a reasonably
small topology. Again debates broke out whether a full area (1000
nodes) was acceptable. It turned out yes, but certainly keeping it
smaller, say to 100-200, would be a good thing if possible.
Geography isn't a consideration unless the links are slow enough to make
route change propagation an issue. Corporate organization (different
departments) CERTAINLY isnt' a consideration, though some people tried
to argue that it was valid to do so.
paul
Johnny, the original DECnet manuals showed pictures of area routers that
were interconnected by WAN links. Each site had its own area number. In fact
the name "area routing" implies clearly that the concept was meant to set up
DECnet networks that were geographically separated.
I ran a fairly large DECnet environment 20 years ago with >20 PDP-11's, >80
VAX systems >600 pc's and several alpha's, plus a few unix systems that ran
DECnet too (in those days DECnet was the multiplatform protocol of choice).
I seprataed each factory in its own DECnet area. DEC Holland got midly
interested in the design because they wondered whether the level 2 routing
overhead wouldn't hurt network performance. Which it didn't :-)
One reason for separating systems in different areas was that rebooting the
pc's would generate so many DECnet state up and down messages that PDP-11's
and the older VAX systems choked in their console output.
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Johnny Billquist
Verzonden: maandag, juni 2010 21:11
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Attaching to hecnet
Brian Hechinger wrote:
Ok, so I should be getting to my plans soon enough here and had some
questions
about how I should set this up.
I'm going to install SIMH on the machine in colo (100mbit connection here
in
the US, so might be useful as a "hub") as well as a small handful of boxes
here at home.
Sounds good.
Should I just use one area? What's the best way to set that up?
Areas in DECnet are not really meant to be associated with physical
location, but rather with organizational. So keep it within one area.
For physically different locations, you might want to use level 1
routers, though. But as the internet nowadays is so fast, using just a
bridge, and pretend that it's all one ethernet segment also works just fine.
Johnny
Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com
Versie: 9.0.830 / Virusdatabase: 271.1.1/2969 - datum van uitgifte: 06/28/10
20:35:00
OK Johnny, talk to me :-)
This is my plan: I intend to modify two systems to try the connection to
HECnet.
1) I have a linux system under Fedora 9 that will run the bridge software
and an Alpha Server 1200 under VMS V8.3 and DECnet phase IV, address 1.1010.
2) a VAXstation 4000 model 90A, running VMS V7.3 and DECnet phase V, in area
44.
I'd like to try that connection without the linux system.
Option 2 is my preferred situation since it removes a by and large unknown
factor from the equation (the linux box).
So, what do I need to know and to do to make this work?
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Johnny Billquist
Verzonden: maandag, juni 2010 21:03
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Attaching to hecnet
H Vlems wrote:
What I meant with the phase III-IV-V answer is that direct connectivity
between a phase V and phase III system won't work. But poor man's routing
will work with a phase IV node in between. Functionality of course is
limited by the phase III host :-)
I wonder if phase III to phase V neccesarily will not work. However, DEC
never guaranteed that it will work, nor did they ever try it.
But you're absolutely right that very few people will have a phase III
system, RT-11 being the most likely candidate?
Probably. Or if someone is running some old versions of other systems.
I've seen the bridge program, but am not sure how to make the .conf file
work. Is it possible to use DECnet address 1.1010 to try and make this
work?
Yes. 1.1010 is not used by anyone, so that node number would be ok to
use to test.
But you also need to talk with me (or someone else) with the bridge
running, to act as the remote end.
Johnny
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Johnny Billquist
Verzonden: maandag, juni 2010 11:02
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Attaching to hecnet
Hi.
H Vlems wrote:
DECnet phase IV nodes are backwards compatible with phase III.
Yes. But the question here was if phase V will interoperate with phase
III. I don't know the answer to that one, but on the other hand, I don't
think anyone around is running phase III anyway.
There are no restrictions in functionality between phase IV nodes and
phase
V as seen by the unpriviledged user. Area routing may be an issue on
Alpha,
and of course ncl is more of a pain to remember than ncp ;-)
True, as far as that goes.
However, I am not sure that a phase V node can operate as a phase IV
area router.
Someone else pointed out that although DEC claimed that alphas could not
be area routers, that information is incorrect, and you can just tell an
Alpha VMS phase IV node to be an area router, if you want to.
However, DECnet+ is phase V, and all bets are off. :-)
And yes, not only are the NCL commands more difficult to remember
(atleast for me), the node name management is way more difficult as
well. Do anyone know how you copy a nodename database from another
machine with DECnet+?
Two questions:
1-May I use area 44?
Sure.
2-Is there a short guide to set up DECnet over IP to connect to HECnet?
Not that I know of. Maybe Mark Wickens have something on hecnet.eu?
My page (http://www.update.uu.se/~bqt/hecnet.html) only have information
about the bridge.
Johnny
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Marc Chametzky
Verzonden: maandag, juni 2010 0:04
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Attaching to hecnet
DECnet-Plus isn't
able to connect, or at least reliably connect to all OS's that can
potentially be on HECnet. I forget what all OS's I was having issues
with, I know one was RSTS/E v10.1, but I want to say it also included
VAX/VMS. Once I *upgraded* my Alpha running OpenVMS to DECnet Phase IV,
all these issues went away. These were things as simple as SET HOST.
It's probably that DECnet-Plus (Phase V) cannot speak with DECnet Phase
III (such as on RSTS/E and TOPS-10/20). That's my guess anyway.
Phase V should be able to communicate with VAX/VMS since that's Phase
IV, which is the gold standard of DECnet, IMHO.
--Marc
Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com
Versie: 9.0.830 / Virusdatabase: 271.1.1/2966 - datum van uitgifte:
06/27/10
08:35:00
Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com
Versie: 9.0.830 / Virusdatabase: 271.1.1/2968 - datum van uitgifte:
06/28/10
08:37:00
Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com
Versie: 9.0.830 / Virusdatabase: 271.1.1/2969 - datum van uitgifte: 06/28/10
20:35:00
There are additional limitations to phase III nodes in a phase IV
network.
Phase III nodes do not have any idea of areas, and all node numbers
must
be below 256. (In short, phase III nodes use a single byte for node
addresses.)
So, a phase III node can only talk with other nodes within the same
area, and only if those nodes have low node numbers.
Another key point: Phase III doesn't support Ethernet -- it only handles point to point (DDCMP and equivalent) links. The network layer messages are different, too. For one thing, the init message has the older routing layer version number in it. For another, in the case of routers, the route vector is sent as a simple full vector rather than as a list of segments with new data (omitting unchanged data) as is done for Phase IV.
It's certainly possible in principle for a Phase V node to understand Phase III routing layer messages; in practice, I doubt this was done and the rules certainly didn't require it.
paul
Brian Hechinger wrote:
Ok, so I should be getting to my plans soon enough here and had some questions
about how I should set this up.
I'm going to install SIMH on the machine in colo (100mbit connection here in
the US, so might be useful as a "hub") as well as a small handful of boxes
here at home.
Sounds good.
Should I just use one area? What's the best way to set that up?
Areas in DECnet are not really meant to be associated with physical location, but rather with organizational. So keep it within one area.
For physically different locations, you might want to use level 1 routers, though. But as the internet nowadays is so fast, using just a bridge, and pretend that it's all one ethernet segment also works just fine.
Johnny
There are additional limitations to phase III nodes in a phase IV network.
Phase III nodes do not have any idea of areas, and all node numbers must be below 256. (In short, phase III nodes use a single byte for node addresses.)
So, a phase III node can only talk with other nodes within the same area, and only if those nodes have low node numbers.
For some applications, PMR can make phase III nodes be able to talk with machines in other areas, or with high numbers.
I have no idea about the rest...
Johnny
Kari Uusim ki wrote:
Yes, indeed. It wasn't even meant to work. Here's an excerpt from the DECnet (Phase IV) manual:
DECnet supports a variety of types of nodes developed during different phases
of DNA implementation. Phase II, III, and IV nodes and DECnet/OSI nodes
can all exist on a network. There are con guration restrictions in such a mixed
network; one major restriction is that only nodes running adjacent phases can
communicate directly, as shown in the following list:
Phase II Phase II
Phase II Phase III
Phase III Phase III
Phase III Phase IV
Phase IV Phase IV
Phase IV DECnet/OSI
DECnet/OSI DECnet/OSI
Later there is mentioned that a Phase III node can exist in an Phase IV area as an end node. It can communicate with a Phase V node through the Phase IV area.
I don't have personal experience with DECnet Phase III.
Regards,
Kari
On 28.6.2010 16:02, H Vlems wrote:
What I meant with the phase III-IV-V answer is that direct connectivity
between a phase V and phase III system won't work. But poor man's routing
will work with a phase IV node in between. Functionality of course is
limited by the phase III host :-)
But you're absolutely right that very few people will have a phase III
system, RT-11 being the most likely candidate?
I've seen the bridge program, but am not sure how to make the .conf file
work. Is it possible to use DECnet address 1.1010 to try and make this work?
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Johnny Billquist
Verzonden: maandag, juni 2010 11:02
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Attaching to hecnet
Hi.
H Vlems wrote:
DECnet phase IV nodes are backwards compatible with phase III.
Yes. But the question here was if phase V will interoperate with phase
III. I don't know the answer to that one, but on the other hand, I don't
think anyone around is running phase III anyway.
There are no restrictions in functionality between phase IV nodes and
phase
V as seen by the unpriviledged user. Area routing may be an issue on
Alpha,
and of course ncl is more of a pain to remember than ncp ;-)
True, as far as that goes.
However, I am not sure that a phase V node can operate as a phase IV
area router.
Someone else pointed out that although DEC claimed that alphas could not
be area routers, that information is incorrect, and you can just tell an
Alpha VMS phase IV node to be an area router, if you want to.
However, DECnet+ is phase V, and all bets are off. :-)
And yes, not only are the NCL commands more difficult to remember
(atleast for me), the node name management is way more difficult as
well. Do anyone know how you copy a nodename database from another
machine with DECnet+?
Two questions:
1-May I use area 44?
Sure.
2-Is there a short guide to set up DECnet over IP to connect to HECnet?
Not that I know of. Maybe Mark Wickens have something on hecnet.eu?
My page (http://www.update.uu.se/~bqt/hecnet.html) only have information
about the bridge.
Johnny
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Marc Chametzky
Verzonden: maandag, juni 2010 0:04
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Attaching to hecnet
DECnet-Plus isn't
able to connect, or at least reliably connect to all OS's that can
potentially be on HECnet. I forget what all OS's I was having issues
with, I know one was RSTS/E v10.1, but I want to say it also included
VAX/VMS. Once I *upgraded* my Alpha running OpenVMS to DECnet Phase IV,
all these issues went away. These were things as simple as SET HOST.
It's probably that DECnet-Plus (Phase V) cannot speak with DECnet Phase
III (such as on RSTS/E and TOPS-10/20). That's my guess anyway.
Phase V should be able to communicate with VAX/VMS since that's Phase
IV, which is the gold standard of DECnet, IMHO.
--Marc
Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com
Versie: 9.0.830 / Virusdatabase: 271.1.1/2966 - datum van uitgifte:
06/27/10
08:35:00
Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com
Versie: 9.0.830 / Virusdatabase: 271.1.1/2968 - datum van uitgifte: 06/28/10
08:37:00
.
H Vlems wrote:
What I meant with the phase III-IV-V answer is that direct connectivity
between a phase V and phase III system won't work. But poor man's routing
will work with a phase IV node in between. Functionality of course is
limited by the phase III host :-)
I wonder if phase III to phase V neccesarily will not work. However, DEC never guaranteed that it will work, nor did they ever try it.
But you're absolutely right that very few people will have a phase III
system, RT-11 being the most likely candidate?
Probably. Or if someone is running some old versions of other systems.
I've seen the bridge program, but am not sure how to make the .conf file
work. Is it possible to use DECnet address 1.1010 to try and make this work?
Yes. 1.1010 is not used by anyone, so that node number would be ok to use to test.
But you also need to talk with me (or someone else) with the bridge running, to act as the remote end.
Johnny
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Johnny Billquist
Verzonden: maandag, juni 2010 11:02
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Attaching to hecnet
Hi.
H Vlems wrote:
DECnet phase IV nodes are backwards compatible with phase III.
Yes. But the question here was if phase V will interoperate with phase III. I don't know the answer to that one, but on the other hand, I don't think anyone around is running phase III anyway.
There are no restrictions in functionality between phase IV nodes and
phase
V as seen by the unpriviledged user. Area routing may be an issue on
Alpha,
and of course ncl is more of a pain to remember than ncp ;-)
True, as far as that goes.
However, I am not sure that a phase V node can operate as a phase IV area router.
Someone else pointed out that although DEC claimed that alphas could not be area routers, that information is incorrect, and you can just tell an Alpha VMS phase IV node to be an area router, if you want to.
However, DECnet+ is phase V, and all bets are off. :-)
And yes, not only are the NCL commands more difficult to remember (atleast for me), the node name management is way more difficult as well. Do anyone know how you copy a nodename database from another machine with DECnet+?
Two questions:
1-May I use area 44?
Sure.
2-Is there a short guide to set up DECnet over IP to connect to HECnet?
Not that I know of. Maybe Mark Wickens have something on hecnet.eu?
My page (http://www.update.uu.se/~bqt/hecnet.html) only have information about the bridge.
Johnny
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Marc Chametzky
Verzonden: maandag, juni 2010 0:04
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Attaching to hecnet
DECnet-Plus isn't
able to connect, or at least reliably connect to all OS's that can
potentially be on HECnet. I forget what all OS's I was having issues
with, I know one was RSTS/E v10.1, but I want to say it also included
VAX/VMS. Once I *upgraded* my Alpha running OpenVMS to DECnet Phase IV,
all these issues went away. These were things as simple as SET HOST.
It's probably that DECnet-Plus (Phase V) cannot speak with DECnet Phase III (such as on RSTS/E and TOPS-10/20). That's my guess anyway.
Phase V should be able to communicate with VAX/VMS since that's Phase IV, which is the gold standard of DECnet, IMHO.
--Marc
Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com Versie: 9.0.830 / Virusdatabase: 271.1.1/2966 - datum van uitgifte:
06/27/10
08:35:00
Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com Versie: 9.0.830 / Virusdatabase: 271.1.1/2968 - datum van uitgifte: 06/28/10
08:37:00
Kari Uusim ki wrote:
On 28.6.2010 12:02, Johnny Billquist wrote:
Hi.
Someone else pointed out that although DEC claimed that alphas could not
be area routers, that information is incorrect, and you can just tell an
Alpha VMS phase IV node to be an area router, if you want to.
However, DECnet+ is phase V, and all bets are off. :-)
There was some versions of DECnet-plus for Alpha which didn't support area routing, but modern versions do.
I believe the official word was that Alpha VMS didn't support phase IV area routing, period.
And yes, not only are the NCL commands more difficult to remember
(atleast for me), the node name management is way more difficult as
well. Do anyone know how you copy a nodename database from another
machine with DECnet+?
If the DECdns is not used, the local namespace (=nodename database) from one node can be exported to a file and the file transferred to another node and then the namespace is imported with decnet_register, which is the utility used for managing the local namespace.
So how do you do that from a phase IV node? I mean, sure, I can output the result of "SHOW KNOWN NODES" to a file. Can a phase V node import that text file?
Two questions:
1-May I use area 44?
Sure.
May I use the area 16?
Yup.
Johnny
Apoligies to all...
That previous message was adressed directly to Jonny, in my mind that is, but my fingers just made a "reply" without checking the "TO:"-line...
/G ran
Hej!
Jag f r v l st lla mig i k n...
N gon emulerad PDP f r det v l bli till en b rjan. Undrar om jag kan k ra area-routing under RSX. Det borde g kan jag gissa utan att l sa p och utan att ha gjort det innan.
andra sidan har jag nog gamla RTR57A p vinden, jag var trots allt SYSMGR p den i ca 5 r, d f r jag k ra en emulerad VAX, t nkte undvika att k ra n gon PWS h r hemma pga buller och el... VMS borde jag kunna skr mma stad p om jag jobbar lite...
S jag fr gar vackert efter area 57!
Jag f r terkomma med adress. Jag vet inte ens s kert om jag har en fast IP-adress h r i l genheten eller ej (k r Tele-2 kabel-TV-internet....). Gissar att jag borde ta reda p detta fakta!
Jag laddade ner och kollade p GW-programvaran, s g att det i configfilen st r n got om
local tmn0 (i alla fall xyz0 =/= eth0) r detta en syntax f r interfacet i just Din unix-version, eller r det interfacet i pcap, eller ?
B sta h lsningar
G ran
Ok, so I should be getting to my plans soon enough here and had some questions
about how I should set this up.
I'm going to install SIMH on the machine in colo (100mbit connection here in
the US, so might be useful as a "hub") as well as a small handful of boxes
here at home.
Should I just use one area? What's the best way to set that up?
Thanks!
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
Marc Chametzky wrote:
DECnet-Plus isn't
able to connect, or at least reliably connect to all OS's that can
potentially be on HECnet. I forget what all OS's I was having
issues
with, I know one was RSTS/E v10.1, but I want to say it also
included
VAX/VMS. Once I *upgraded* my Alpha running OpenVMS to DECnet Phase
IV,
all these issues went away. These were things as simple as SET
HOST.
It's probably that DECnet-Plus (Phase V) cannot speak with DECnet
Phase
III (such as on RSTS/E and TOPS-10/20). That's my guess anyway.
Phase V should be able to communicate with VAX/VMS since that's
Phase
IV, which is the gold standard of DECnet, IMHO.
=20
TOPS-20 DECnet is phase IV, and I believe that the latest version of
DECnet for RSTS/E is also phase IV.
Correct, starting with RSTS/E V9.3 (DECnet/E 4.0). Older versions (V7.0
and up) are Phase III. RT-11 is Phase III as far as I know.
paul
Yes, RT-11 IS phase III. Don't get me started.
-Steve
For those of you interested, the latest version of NETUPDATE.COM is available
at SGC::[DECNET]NETUPDATE.COM. This is now its permanent home.
This file may live anywhere you wish on your system. It is much more advanced
than any previous version. You do not need to edit this one, in fact if you do
so, then the "auto-update" feature will not function. It depends on the file
version to keep track of itself. You will need privileges to execute this.
It is supported on VMS DECnet Phase-IV nodes only! The first run should be
either using "@" or, "submit/user=SYSTEM".
The procdure is well documented so that you will be able use it as is, or
customize it via logicals. The logicals (and their defaults) are:
NETUPDATE_MASTER_NODE "MIM" !node to update from
NETUPDATE_SUBMIT_QUEUE "SYS$BATCH" !batch queue to execute from
NETUPDATE_TIME_DELTA "+7-" !update every 7 days
NETUPDATE_UPDATE_FLAG "FALSE" !do NOT automatically update NETUPDATE
MIM contains the HECnet master nodename database. If you have multiple
machines in your environment, then you should choose one machine to update from
MIM:: and the others should update locally from your "master" node. This will
minimize the loading on MIM::. Let's try to do that please. I don't want to
hear about any problems that this "may" cause MIM:: :-)
SYS$BATCH is on most machines so this made sense to make it the default batch
queue to use. My systems have dedicated system management queues so I change
the value of this logical. In my case it runs on SYS$INIT2. If you would like
more information about how my startups are optimized then send mail directly.
It seems that running this update procedure every 7 days is sufficient for
most systems within HECnet. You are certainly free to change the default to
whatever you need. You can always manually force the batch job to run at any
time should you need to. It will resubmit automatically and revert to your
defaults.
NETUPDATE by default will NOT update itself to the latest version. I have
decided that you need to make this decision for yourself. I do encourage you
to allow it to self-update but I will NOT force anyone to do so.
These logicals should be defined is SYS$COMMON:[SYSMGR]SYLOGICALS.COM should
you choose to use them. Again, never never edit NETUPDATE.COM directly.
Here are "my" suggested values for SYLOGICALS.COM:
$ DSE == "DEFINE/SYSTEM/EXECUTIVE_MODE"
$ DSE NETUPDATE_MASTER_NODE "MIM" !update from MIM::
$ DSE NETUPDATE_SUBMIT_QUEUE "SYS$BATCH" !rum from SYS$BATCH
$ DSE NETUPDATE_TIME_DELTA "+7-" !update every 7 days
$ DSE NETUPDATE_UPDATE_FLAG "TRUE" !update NETUPDATE.COM
If you have any questions or problems please let me know. This has been in
field test for a while (thank you to those who allowed me to "abuse" your
system(s)). This version is edit level 4 (and so is the file version). Edit
levels 5 and 6 are under development with 5 soon to be submitted for field
testing. If you have a wish list item for this process, let me know. I will
take a look and we can go from there.
Enjoy!
-Steve
Correct, starting with RSTS/E V9.3 (DECnet/E 4.0). Older versions (V7.0
and up) are Phase III. RT-11 is Phase III as far as I know.
Ah, that's what I was remembering. When I had set up a RSTS system some time back, it was a V7 system and that's what was Phase III in my memory. My current RSTS system is indeed Phase IV.
--Marc
Marc Chametzky wrote:
DECnet-Plus isn't
able to connect, or at least reliably connect to all OS's that can
potentially be on HECnet. I forget what all OS's I was having
issues
with, I know one was RSTS/E v10.1, but I want to say it also
included
VAX/VMS. Once I *upgraded* my Alpha running OpenVMS to DECnet Phase
IV,
all these issues went away. These were things as simple as SET
HOST.
It's probably that DECnet-Plus (Phase V) cannot speak with DECnet
Phase
III (such as on RSTS/E and TOPS-10/20). That's my guess anyway.
Phase V should be able to communicate with VAX/VMS since that's
Phase
IV, which is the gold standard of DECnet, IMHO.
TOPS-20 DECnet is phase IV, and I believe that the latest version of
DECnet for RSTS/E is also phase IV.
Correct, starting with RSTS/E V9.3 (DECnet/E 4.0). Older versions (V7.0
and up) are Phase III. RT-11 is Phase III as far as I know.
paul
Yes, indeed. It wasn't even meant to work. Here's an excerpt from the
DECnet (Phase IV) manual:
DECnet supports a variety of types of nodes developed during different
phases
of DNA implementation. Phase II, III, and IV nodes and DECnet/OSI nodes
can all exist on a network. There are con guration restrictions in such
a mixed
network; one major restriction is that only nodes running adjacent
phases can
communicate directly, ...
Exactly. The other restriction is that both endpoints of an application connection have to understand the same protocol. Since there haven't been a whole lot of application layer changes between Phase III and IV, that shouldn't be a big issue. The most obvious one is "set host" which switched from the OS-specific versions to Cterm (in some operating systems). But the old ones are often still supported. Things like file transfer are likely to be fine.
Phase II is a different story, but implementations that old are probably very hard to find.
Later there is mentioned that a Phase III node can exist in an Phase IV
area as an end node. It can communicate with a Phase V node through
the Phase IV area.
paul
Yes, indeed. It wasn't even meant to work. Here's an excerpt from the DECnet (Phase IV) manual:
DECnet supports a variety of types of nodes developed during different phases
of DNA implementation. Phase II, III, and IV nodes and DECnet/OSI nodes
can all exist on a network. There are con guration restrictions in such a mixed
network; one major restriction is that only nodes running adjacent phases can
communicate directly, as shown in the following list:
Phase II Phase II
Phase II Phase III
Phase III Phase III
Phase III Phase IV
Phase IV Phase IV
Phase IV DECnet/OSI
DECnet/OSI DECnet/OSI
Later there is mentioned that a Phase III node can exist in an Phase IV area as an end node. It can communicate with a Phase V node through the Phase IV area.
I don't have personal experience with DECnet Phase III.
Regards,
Kari
On 28.6.2010 16:02, H Vlems wrote:
What I meant with the phase III-IV-V answer is that direct connectivity
between a phase V and phase III system won't work. But poor man's routing
will work with a phase IV node in between. Functionality of course is
limited by the phase III host :-)
But you're absolutely right that very few people will have a phase III
system, RT-11 being the most likely candidate?
I've seen the bridge program, but am not sure how to make the .conf file
work. Is it possible to use DECnet address 1.1010 to try and make this work?
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Johnny Billquist
Verzonden: maandag, juni 2010 11:02
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Attaching to hecnet
Hi.
H Vlems wrote:
DECnet phase IV nodes are backwards compatible with phase III.
Yes. But the question here was if phase V will interoperate with phase
III. I don't know the answer to that one, but on the other hand, I don't
think anyone around is running phase III anyway.
There are no restrictions in functionality between phase IV nodes and
phase
V as seen by the unpriviledged user. Area routing may be an issue on
Alpha,
and of course ncl is more of a pain to remember than ncp ;-)
True, as far as that goes.
However, I am not sure that a phase V node can operate as a phase IV
area router.
Someone else pointed out that although DEC claimed that alphas could not
be area routers, that information is incorrect, and you can just tell an
Alpha VMS phase IV node to be an area router, if you want to.
However, DECnet+ is phase V, and all bets are off. :-)
And yes, not only are the NCL commands more difficult to remember
(atleast for me), the node name management is way more difficult as
well. Do anyone know how you copy a nodename database from another
machine with DECnet+?
Two questions:
1-May I use area 44?
Sure.
2-Is there a short guide to set up DECnet over IP to connect to HECnet?
Not that I know of. Maybe Mark Wickens have something on hecnet.eu?
My page (http://www.update.uu.se/~bqt/hecnet.html) only have information
about the bridge.
Johnny
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Marc Chametzky
Verzonden: maandag, juni 2010 0:04
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Attaching to hecnet
DECnet-Plus isn't
able to connect, or at least reliably connect to all OS's that can
potentially be on HECnet. I forget what all OS's I was having issues
with, I know one was RSTS/E v10.1, but I want to say it also included
VAX/VMS. Once I *upgraded* my Alpha running OpenVMS to DECnet Phase IV,
all these issues went away. These were things as simple as SET HOST.
It's probably that DECnet-Plus (Phase V) cannot speak with DECnet Phase
III (such as on RSTS/E and TOPS-10/20). That's my guess anyway.
Phase V should be able to communicate with VAX/VMS since that's Phase
IV, which is the gold standard of DECnet, IMHO.
--Marc
Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com
Versie: 9.0.830 / Virusdatabase: 271.1.1/2966 - datum van uitgifte:
06/27/10
08:35:00
Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com
Versie: 9.0.830 / Virusdatabase: 271.1.1/2968 - datum van uitgifte: 06/28/10
08:37:00
.
What I meant with the phase III-IV-V answer is that direct connectivity
between a phase V and phase III system won't work. But poor man's routing
will work with a phase IV node in between. Functionality of course is
limited by the phase III host :-)
But you're absolutely right that very few people will have a phase III
system, RT-11 being the most likely candidate?
I've seen the bridge program, but am not sure how to make the .conf file
work. Is it possible to use DECnet address 1.1010 to try and make this work?
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Johnny Billquist
Verzonden: maandag, juni 2010 11:02
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Attaching to hecnet
Hi.
H Vlems wrote:
DECnet phase IV nodes are backwards compatible with phase III.
Yes. But the question here was if phase V will interoperate with phase
III. I don't know the answer to that one, but on the other hand, I don't
think anyone around is running phase III anyway.
There are no restrictions in functionality between phase IV nodes and
phase
V as seen by the unpriviledged user. Area routing may be an issue on
Alpha,
and of course ncl is more of a pain to remember than ncp ;-)
True, as far as that goes.
However, I am not sure that a phase V node can operate as a phase IV
area router.
Someone else pointed out that although DEC claimed that alphas could not
be area routers, that information is incorrect, and you can just tell an
Alpha VMS phase IV node to be an area router, if you want to.
However, DECnet+ is phase V, and all bets are off. :-)
And yes, not only are the NCL commands more difficult to remember
(atleast for me), the node name management is way more difficult as
well. Do anyone know how you copy a nodename database from another
machine with DECnet+?
Two questions:
1-May I use area 44?
Sure.
2-Is there a short guide to set up DECnet over IP to connect to HECnet?
Not that I know of. Maybe Mark Wickens have something on hecnet.eu?
My page (http://www.update.uu.se/~bqt/hecnet.html) only have information
about the bridge.
Johnny
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Marc Chametzky
Verzonden: maandag, juni 2010 0:04
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Attaching to hecnet
DECnet-Plus isn't
able to connect, or at least reliably connect to all OS's that can
potentially be on HECnet. I forget what all OS's I was having issues
with, I know one was RSTS/E v10.1, but I want to say it also included
VAX/VMS. Once I *upgraded* my Alpha running OpenVMS to DECnet Phase IV,
all these issues went away. These were things as simple as SET HOST.
It's probably that DECnet-Plus (Phase V) cannot speak with DECnet Phase
III (such as on RSTS/E and TOPS-10/20). That's my guess anyway.
Phase V should be able to communicate with VAX/VMS since that's Phase
IV, which is the gold standard of DECnet, IMHO.
--Marc
Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com
Versie: 9.0.830 / Virusdatabase: 271.1.1/2966 - datum van uitgifte:
06/27/10
08:35:00
Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com
Versie: 9.0.830 / Virusdatabase: 271.1.1/2968 - datum van uitgifte: 06/28/10
08:37:00
