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
call me...
603.791.0267
-Steve
Steve told me to take it down, something about loops. Does it need to
be up?
Sampsa
On 3 Jun 2010, at 14:52, Bob Armstrong wrote:
Sampsa -
Do you know why the Multinet link from CHARON to GORVAX is down?
Bob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf
Of Sampsa Laine
Sent: Thursday, June 03, 2010 6:42 AM
To: hecnet at Update.UU.SE
Subject: [HECnet] Site renumbering (new area 8) + bits and bobs
Guys,
We (well mostly Steve D) today did a renumbering exercise on my
systems (CHIMPY, RHESUS, GORVAX and FIDOGW) into a new area, 8.
Please be sure to pull a new node database off MIM to continue to be
able to reach my site.
Also, because of the renumbering, MIM is no longer getting annoying
error messages so I am running the phone directory poller again, it's
at http://rhesus.sampsa.com/hecnetdir.html
Sampsa
Bob Armstrong wrote:
Ooops. MIM just crashed... Rebooting now...
RSX must have a limit on the number of simultaneous NCP COPY KNOWN NODES
commands :-)
By the way, as a more literal answer (I'm totally ignoring the smiley, as I hope you note... :-) )
.ncp sho obj 19
Object summary as of 3-JUN-10 16:15:43
Object Name Copies User Verification
19 NIC$$$ 5 Default Inspect
.
So, there is a limit, and it's 5... (Yes, I could change it, but I don't think I need to.)
Johnny
Bob Armstrong wrote:
Ooops. MIM just crashed... Rebooting now...
RSX must have a limit on the number of simultaneous NCP COPY KNOWN NODES
commands :-)
More likely is the rather odd and experimental type of system MIM is, being an emulated PDP-11/74 multiprocessor system... (I use it to help debugging Wilsons E11 11/74 emulation, and there are some bugs still around somewhere...)
Johnny
