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
