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
I see. He didn't mention that to me.
Sorry - I tried to answer your phone call, but it fails because CHARON
doesn't have the right address for CHIMPY.
Actually, yes, I'd like to have the link to GORVAX as a redundant route to
the rest of the nodes. There's no problem with redundant routes using
Multinet point to point links - DECnet will just pick the path with the
least cost to the destination and ignore the others. If the least cost path
goes down, then DECnet will pick the new least cost path, whatever that
might be.
There are, OTOH, issues with creating loops using the bridge program, but
that has nothing to do with Multinet.
BTW, who is Steve and how come he's setting himself up as the central
routing hub for HECnet? In general I'm not comfortable with any
architecture that has a single point of failure, no matter how many machines
and how much bandwidth he may have.
Bob
-----Original Message-----
From: Sampsa Laine [mailto:sampsa at mac.com]
Sent: Thursday, June 03, 2010 6:53 AM
To: bob at jfcl.com
Cc: Steve Davidson
Subject: Re: [HECnet] Site renumbering (new area 8) + bits and bobs
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