You can always run SIMH of course of another box...
Sampsa
On 4 Jun 2010, at 23:40, Mark Wickens wrote:
On Fri, 2010-06-04 at 15:29 -0700, Zane H. Healy wrote:
Am I remembering correctly that in order to have a DECnet Phase IV area
router you need to be running a VAX?
Can Phase V act as an area router?
I'm contemplating figuring out what Alpha has the lowest power requirements,
and bringing it online in place of MONK (a very power hungry XP1000 with
plenty of external drives).
Then again a VAX would probably pull even less. Believe it or not, the
"killer app" that I'm having a hard time living without is DEC Document.
Zane
My power consumption page might help a bit:
http://lakesdev.blogspot.com/2008/09/power-consumption-of-computers-and.html
The VAXstation 4000/VLC takes the lowest power but at about 6 VUPS it is
quite slow. The 4000/60 and 4000/90 (BUBBLE) take about 100 Watts, which
is twice as much, but are *so* much more usable.
In terms of alpha, the lowest power I've found so far is the Alphaserver
300 4/266 (TIGER) which clocks at about 100 watts. The Alphaserver 1000A
runs at about 180 watts which is pretty good given the expansion
possibilities (it has a BA356 8 drive enclosure built in).
I'm currently running a BUBBLE and TIGER 24/7 which is a VAX and Alpha
node for 200 watts total.
Mark.
On Fri, 2010-06-04 at 15:29 -0700, Zane H. Healy wrote:
Am I remembering correctly that in order to have a DECnet Phase IV area
router you need to be running a VAX?
Can Phase V act as an area router?
I'm contemplating figuring out what Alpha has the lowest power requirements,
and bringing it online in place of MONK (a very power hungry XP1000 with
plenty of external drives).
Then again a VAX would probably pull even less. Believe it or not, the
"killer app" that I'm having a hard time living without is DEC Document.
Zane
My power consumption page might help a bit:
http://lakesdev.blogspot.com/2008/09/power-consumption-of-computers-and.html
The VAXstation 4000/VLC takes the lowest power but at about 6 VUPS it is
quite slow. The 4000/60 and 4000/90 (BUBBLE) take about 100 Watts, which
is twice as much, but are *so* much more usable.
In terms of alpha, the lowest power I've found so far is the Alphaserver
300 4/266 (TIGER) which clocks at about 100 watts. The Alphaserver 1000A
runs at about 180 watts which is pretty good given the expansion
possibilities (it has a BA356 8 drive enclosure built in).
I'm currently running a BUBBLE and TIGER 24/7 which is a VAX and Alpha
node for 200 watts total.
Mark.
Am I remembering correctly that in order to have a DECnet Phase IV area
router you need to be running a VAX?
It's been ages, but I didn't think this was a requirement. A quick Google check found this article - http://www.openvms.compaq.com/wizard/wiz_5081.html - which does say that a VAX is required. It mentions DECnet Phase V routing supporting "host-based routing".
As an aside, the only VAX routing requirement that I did remember was that MRGATE, the Message Router gateway product, was VAX only, so for those systems running Message Router with Alphas, they'd have to keep a VAX around to get their content out. Back in those days, I worked at Innosoft and we had a product, PMDF-MR, which allowed for e-mail gatewaying to Message Router without requiring a VAX since we emulated MRGATE.
--Marc
Am I remembering correctly that in order to have a DECnet Phase IV area
router you need to be running a VAX?
Can Phase V act as an area router?
I'm contemplating figuring out what Alpha has the lowest power requirements,
and bringing it online in place of MONK (a very power hungry XP1000 with
plenty of external drives).
Then again a VAX would probably pull even less. Believe it or not, the
"killer app" that I'm having a hard time living without is DEC Document.
Zane
Folks
I've just finished configuring my Alphaserver 300 4/266 running Digital
Unix 4.0G to be on HECnet via DECNET/OSI basic configuration. I don't
know whether there are other Digital Unix systems out there! The new
node is 1.258, TIGER, requiring a node list update to find.
Next step is to install the Mailbus 400 SMTP Gateway...
Regards, Mark.
I probably should have pointed out that if you have multiple machines then you can make one responsible for using this procedure and all others acquiring their updates from that updated machine. Just change the "MIM" in the procedure to your local machine that was updated using MIM. Distributed is *the* way to go here. No need to beat on MIM. MIM has been very good to all of us!
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE on behalf of Sampsa Laine
Sent: Fri 6/4/2010 10:52
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Network nodename database procedure available
I say we all run it at EXACTLY the same time, see if we can crash MIM
on a weekly basis too :)
Sampsa
On 4 Jun 2010, at 15:48, Steve Davidson wrote:
I have written a quick (and dirty) little procedure to update the
network database on VMS platforms. This procedure (a batch job),
will acquire the latest database from MIM:: on a weekly basis.
The procedure is located at MIM::[DECNET]NETUPDATE.COM (thanks
Johnny). I will update it from time-to-time as necessary and re-
post that fact here.
I would store this procedure in a "common" place (ie SYS$COMMON:
[SYSMGR]) or if you have it, a dedicated area that you already store
command/batch job procedures (files). Pick a time and then run it
as a normal command procedure. It is self-submitting so it will
happily re-submit as part of the procedure. The procedure makes two
assumptions: First that the batch queue you will be using is SYS
$BATCH, and second that you want the update to occur on a weekly
basis. You are of course free to change either.
As always, please review any file that is submitted before
committing to execute it, and if you have questions just ask.
Regards,
-Steve
If you manage to crash MIM, it is because of bugs in various places, not because of overloading...
RSX itself is normally stable as a rock. :-)
And so is E11 (if I wasn't running the experimental 11/74 stuff...).
Johnny
Sampsa Laine wrote:
I say we all run it at EXACTLY the same time, see if we can crash MIM on a weekly basis too :)
Sampsa
On 4 Jun 2010, at 15:48, Steve Davidson wrote:
I have written a quick (and dirty) little procedure to update the network database on VMS platforms. This procedure (a batch job), will acquire the latest database from MIM:: on a weekly basis.
The procedure is located at MIM::[DECNET]NETUPDATE.COM (thanks Johnny). I will update it from time-to-time as necessary and re-post that fact here.
I would store this procedure in a "common" place (ie SYS$COMMON:[SYSMGR]) or if you have it, a dedicated area that you already store command/batch job procedures (files). Pick a time and then run it as a normal command procedure. It is self-submitting so it will happily re-submit as part of the procedure. The procedure makes two assumptions: First that the batch queue you will be using is SYS$BATCH, and second that you want the update to occur on a weekly basis. You are of course free to change either.
As always, please review any file that is submitted before committing to execute it, and if you have questions just ask.
Regards,
-Steve
My next version might add in a random delay to prevent such a problem. I was thinking about that after seeing some of the previous mail... :-)
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE on behalf of Sampsa Laine
Sent: Fri 6/4/2010 10:52
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Network nodename database procedure available
I say we all run it at EXACTLY the same time, see if we can crash MIM
on a weekly basis too :)
Sampsa
On 4 Jun 2010, at 15:48, Steve Davidson wrote:
I have written a quick (and dirty) little procedure to update the
network database on VMS platforms. This procedure (a batch job),
will acquire the latest database from MIM:: on a weekly basis.
The procedure is located at MIM::[DECNET]NETUPDATE.COM (thanks
Johnny). I will update it from time-to-time as necessary and re-
post that fact here.
I would store this procedure in a "common" place (ie SYS$COMMON:
[SYSMGR]) or if you have it, a dedicated area that you already store
command/batch job procedures (files). Pick a time and then run it
as a normal command procedure. It is self-submitting so it will
happily re-submit as part of the procedure. The procedure makes two
assumptions: First that the batch queue you will be using is SYS
$BATCH, and second that you want the update to occur on a weekly
basis. You are of course free to change either.
As always, please review any file that is submitted before
committing to execute it, and if you have questions just ask.
Regards,
-Steve
I say we all run it at EXACTLY the same time, see if we can crash MIM on a weekly basis too :)
Sampsa
On 4 Jun 2010, at 15:48, Steve Davidson wrote:
I have written a quick (and dirty) little procedure to update the network database on VMS platforms. This procedure (a batch job), will acquire the latest database from MIM:: on a weekly basis. The procedure is located at MIM::[DECNET]NETUPDATE.COM (thanks Johnny). I will update it from time-to-time as necessary and re-post that fact here. I would store this procedure in a "common" place (ie SYS$COMMON:[SYSMGR]) or if you have it, a dedicated area that you already store command/batch job procedures (files). Pick a time and then run it as a normal command procedure. It is self-submitting so it will happily re-submit as part of the procedure. The procedure makes two assumptions: First that the batch queue you will be using is SYS$BATCH, and second that you want the update to occur on a weekly basis. You are of course free to change either. As always, please review any file that is submitted before committing to execute it, and if you have questions just ask. Regards, -Steve
I should just point out that the location is actually
MIM::US:[DECNET]NETUPDATE.COM
however, US:[DECNET] is the default device and directory for anonymous access to MIM:: anyway, so you can skip those parts. :-)
Johnny
Steve Davidson wrote:
I have written a quick (and dirty) little procedure to update the network database on VMS platforms. This procedure (a batch job), will acquire the latest database from MIM:: on a weekly basis.
The procedure is located at MIM::[DECNET]NETUPDATE.COM (thanks Johnny). I will update it from time-to-time as necessary and re-post that fact here.
I would store this procedure in a "common" place (ie SYS$COMMON:[SYSMGR]) or if you have it, a dedicated area that you already store command/batch job procedures (files). Pick a time and then run it as a normal command procedure. It is self-submitting so it will happily re-submit as part of the procedure. The procedure makes two assumptions: First that the batch queue you will be using is SYS$BATCH, and second that you want the update to occur on a weekly basis. You are of course free to change either.
As always, please review any file that is submitted before committing to execute it, and if you have questions just ask.
Regards,
-Steve
