That is just a simple check for end of file on read. When it reaches
the EOF it closes the open file(s). The early close statements include
error checking as well. That allows debugging and ensures that the file
is closed before the attempted open.
BTW - This procedure gets around all the issues that Johnny's procedure
may be running into. It does the right thing for all VMS systems. It
also skips the current area so that local databases that are
cluster-based will not get clobbered. This can be a problem if DECnet
is used for cluster communications. It does not have to be regenerated
each time a database update occurs. The data file it uses is
regenerated automatically by Johnny's procedures. That's the reason for
the file in the first place.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Dennis Boone
Sent: Tuesday, February 19, 2013 10:41
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] HECnet Area Request
Grab the file SG1::[DECNET]NU2.COM. Ignore the errors.
It does depend > on MIM being defined as 1.13. This
procedure makes use of the file >
MIM::DU4:[DECNET]NODENAMES.DAT. Johnny creates this file for
this > procedure. I will not update your area nodes - that
is your > responsibility. It can be run interactively or
via batch. It must be > run from a priv'd account.
Steve,
Edumacation question. There are a number of places in
NU2.COM where it uses the switch /end_fo_file= [sic]
Unless I'm missing something "meta" about how this thing
works, and assuming it _does_ work, that succeeds in spite of
the typo because...
...DCL only looks at the first 4?
De
Gerry,
Maisa is still there, but I had to move it to another location, so you have to telnet using ip address 212.226.161.98.
--Saku
On Tue, Feb 19, 2013 at 1:22 PM, G. <gerry77 at mail.com> wrote:
Once upon a time, when I wanted to play with HECnet or check something, I used
to telnet and login into a VMS node called MAISA, and from there I was able to
access the whole HECnet. Now MAISA seems long gone and today I remembered that
I can directly telnet to MIM, and so I did. But now I'm wondering wether is
somewhere available a publicly accessible list of telnetable HECnet nodes
offering guest access to the network... Is there something of that sort? :)
Thanks!
G.
Grab the file SG1::[DECNET]NU2.COM. Ignore the errors. It does depend
on MIM being defined as 1.13. This procedure makes use of the file
MIM::DU4:[DECNET]NODENAMES.DAT. Johnny creates this file for this
procedure. I will not update your area nodes - that is your
responsibility. It can be run interactively or via batch. It must be
run from a priv'd account.
Steve,
Edumacation question. There are a number of places in NU2.COM where it
uses the switch /end_fo_file= [sic]
Unless I'm missing something "meta" about how this thing works, and
assuming it _does_ work, that succeeds in spite of the typo because...
...DCL only looks at the first 4?
De
On Tue, Feb 19, 2013 at 01:32:45PM +0100, Johnny Billquist wrote:
On 2013-02-19 13:16, Erik Olofsen wrote:
May be it is best if FIX.COM does not change the node parameters
of those in the local area.
I'm very open to suggestions on how to rewrite it. But how do you
recognize what nodes are in the local area?
It could be done with a procedure that copies the node list from MIM,
reads records and compares the area with f$getsyi("node_area"), or
in a loop of copy commands you show below.
On the other hand, your solution of purging/clearing names only
would only affect unregistered names.
Eh? The purging of names only is what I really should have done to start
with. The intent is to get the nodename database matching the "official"
one. Since sometimes nodes are not just added, but also moved, the old
definitions needs to be cleared before new ones added. That is the whole
reason I had to put the purge in there.
I think we agree :)
Would the ncp copy command from MIM work (although I'm not sure
it is completely safe)?
NCP COPY from MIM would work just perfect, and have done so for many
years. However, for some reason, MIM stopped listing all known nodes at
request recently. I suspect there is a bug or something in RSX, possibly
related to the number of nodes in the database, which cause the COPY
command to not get all nodes anymore.
MIM still knows all nodes, but if you ask it to list them, it will show
everything up to about area 11, and after that, only a select few.
If you do one area at a time, it works correct.
Hmm, maybe you could do something like this on VMS nodes instead:
COPY NODE 1.* FROM MIM TO BOTH
COPY NODE 2.* FROM MIM TO BOTH
.
.
.
down to area 63... That would perhaps also work.
Yes, I need to see if I can figure out why RSX suddenly stopped behaving
well, but in the meanwhile...
Johnny
Erik
On Tue, Feb 19, 2013 at 12:54:57PM +0100, Johnny Billquist wrote:
On 2013-02-19 08:19, Erik Olofsen wrote:
Johnny,
After the "define node"s in FIX.COM without "set node" I thought it would
be easiest to reboot, which gave errors reading the data base, and I think
this happened because the executor data had also been purged. After setting
the executor data, I could define all nodes.
Oh! Good point. I forgot about the volatile database. I'll fix that.
What happened with the executor data? What should I fix?
Johnny
Erik
On Tue, Feb 19, 2013 at 02:02:59AM +0100, Johnny Billquist wrote:
On 2013-02-19 01:48, Ian McLaughlin wrote:
Yes, I would like this. I assume that you are the authoritive list, so I have no need to keep any data on my end. A generic script that I can execute on the command line that clears and updates all in one would be great.
Ok. Done. For VMS users, just grab MIM::FIX.COM, and run it under DCL,
with appropriate privileges, and you'll have an up-to-date nodename
database.
Johnny
Thanks.
Ian
Sent from my iPad
On 2013-02-18, at 4:36 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2013-02-19 01:29, Johnny Billquist wrote:
On 2013-02-18 19:28, Ian McLaughlin wrote:
On 2013-02-18, at 10:19 AM, "Brian Schenkenberger, VAXman-"
<system at TMESIS.COM> wrote:
$ PIPE MCR NCP < FIX.CMD
When I do this, I get a bunch of errors like:
%NCP-W-INVPVA, Invalid parameter value , Name
Remote node = 32.5 (YELLOW)
Am I doing something wrong?
Nope. (This on a VMS box with a rather outdated nodename database):
$ mcr ncp
NCP>sho nod yellow
Node Volatile Summary as of 19-FEB-2013 01:26:09
Node State Active Delay Circuit Next node
Links
32.5 (YELLOW) ISA-0 1.13 (MIM)
NCP>tell mim sho nod yellow
Node Volatile Summary as of 19-FEB-2013 01:26:16
Node State Active Delay Circuit Next node
Links
13.5 (YELLOW)
Notice that the node YELLOW already exists, but with another number.
That cause an error when you try and set it.
You need to clear nodes where you see that error.
By the way, I could do a generic clear in the VMS command procedure, before starting the defines. Would people prefer that?
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
---
Filter service subscribers can train this email as spam or not-spam here: http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=76F0C5CA7A2C11E29…
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2013-02-19 13:16, Erik Olofsen wrote:
May be it is best if FIX.COM does not change the node parameters
of those in the local area.
I'm very open to suggestions on how to rewrite it. But how do you recognize what nodes are in the local area?
On the other hand, your solution of purging/clearing names only
would only affect unregistered names.
Eh? The purging of names only is what I really should have done to start with. The intent is to get the nodename database matching the "official" one. Since sometimes nodes are not just added, but also moved, the old definitions needs to be cleared before new ones added. That is the whole reason I had to put the purge in there.
Would the ncp copy command from MIM work (although I'm not sure
it is completely safe)?
NCP COPY from MIM would work just perfect, and have done so for many years. However, for some reason, MIM stopped listing all known nodes at request recently. I suspect there is a bug or something in RSX, possibly related to the number of nodes in the database, which cause the COPY command to not get all nodes anymore.
MIM still knows all nodes, but if you ask it to list them, it will show everything up to about area 11, and after that, only a select few.
If you do one area at a time, it works correct.
Hmm, maybe you could do something like this on VMS nodes instead:
COPY NODE 1.* FROM MIM TO BOTH
COPY NODE 2.* FROM MIM TO BOTH
.
.
.
down to area 63... That would perhaps also work.
Yes, I need to see if I can figure out why RSX suddenly stopped behaving well, but in the meanwhile...
Johnny
Erik
On Tue, Feb 19, 2013 at 12:54:57PM +0100, Johnny Billquist wrote:
On 2013-02-19 08:19, Erik Olofsen wrote:
Johnny,
After the "define node"s in FIX.COM without "set node" I thought it would
be easiest to reboot, which gave errors reading the data base, and I think
this happened because the executor data had also been purged. After setting
the executor data, I could define all nodes.
Oh! Good point. I forgot about the volatile database. I'll fix that.
What happened with the executor data? What should I fix?
Johnny
Erik
On Tue, Feb 19, 2013 at 02:02:59AM +0100, Johnny Billquist wrote:
On 2013-02-19 01:48, Ian McLaughlin wrote:
Yes, I would like this. I assume that you are the authoritive list, so I have no need to keep any data on my end. A generic script that I can execute on the command line that clears and updates all in one would be great.
Ok. Done. For VMS users, just grab MIM::FIX.COM, and run it under DCL,
with appropriate privileges, and you'll have an up-to-date nodename
database.
Johnny
Thanks.
Ian
Sent from my iPad
On 2013-02-18, at 4:36 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2013-02-19 01:29, Johnny Billquist wrote:
On 2013-02-18 19:28, Ian McLaughlin wrote:
On 2013-02-18, at 10:19 AM, "Brian Schenkenberger, VAXman-"
<system at TMESIS.COM> wrote:
$ PIPE MCR NCP < FIX.CMD
When I do this, I get a bunch of errors like:
%NCP-W-INVPVA, Invalid parameter value , Name
Remote node = 32.5 (YELLOW)
Am I doing something wrong?
Nope. (This on a VMS box with a rather outdated nodename database):
$ mcr ncp
NCP>sho nod yellow
Node Volatile Summary as of 19-FEB-2013 01:26:09
Node State Active Delay Circuit Next node
Links
32.5 (YELLOW) ISA-0 1.13 (MIM)
NCP>tell mim sho nod yellow
Node Volatile Summary as of 19-FEB-2013 01:26:16
Node State Active Delay Circuit Next node
Links
13.5 (YELLOW)
Notice that the node YELLOW already exists, but with another number.
That cause an error when you try and set it.
You need to clear nodes where you see that error.
By the way, I could do a generic clear in the VMS command procedure, before starting the defines. Would people prefer that?
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
---
Filter service subscribers can train this email as spam or not-spam here: http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=76F0C5CA7A2C11E29…
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
May be it is best if FIX.COM does not change the node parameters
of those in the local area.
On the other hand, your solution of purging/clearing names only
would only affect unregistered names.
Would the ncp copy command from MIM work (although I'm not sure
it is completely safe)?
Erik
On Tue, Feb 19, 2013 at 12:54:57PM +0100, Johnny Billquist wrote:
On 2013-02-19 08:19, Erik Olofsen wrote:
Johnny,
After the "define node"s in FIX.COM without "set node" I thought it would
be easiest to reboot, which gave errors reading the data base, and I think
this happened because the executor data had also been purged. After setting
the executor data, I could define all nodes.
Oh! Good point. I forgot about the volatile database. I'll fix that.
What happened with the executor data? What should I fix?
Johnny
Erik
On Tue, Feb 19, 2013 at 02:02:59AM +0100, Johnny Billquist wrote:
On 2013-02-19 01:48, Ian McLaughlin wrote:
Yes, I would like this. I assume that you are the authoritive list, so I have no need to keep any data on my end. A generic script that I can execute on the command line that clears and updates all in one would be great.
Ok. Done. For VMS users, just grab MIM::FIX.COM, and run it under DCL,
with appropriate privileges, and you'll have an up-to-date nodename
database.
Johnny
Thanks.
Ian
Sent from my iPad
On 2013-02-18, at 4:36 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2013-02-19 01:29, Johnny Billquist wrote:
On 2013-02-18 19:28, Ian McLaughlin wrote:
On 2013-02-18, at 10:19 AM, "Brian Schenkenberger, VAXman-"
<system at TMESIS.COM> wrote:
$ PIPE MCR NCP < FIX.CMD
When I do this, I get a bunch of errors like:
%NCP-W-INVPVA, Invalid parameter value , Name
Remote node = 32.5 (YELLOW)
Am I doing something wrong?
Nope. (This on a VMS box with a rather outdated nodename database):
$ mcr ncp
NCP>sho nod yellow
Node Volatile Summary as of 19-FEB-2013 01:26:09
Node State Active Delay Circuit Next node
Links
32.5 (YELLOW) ISA-0 1.13 (MIM)
NCP>tell mim sho nod yellow
Node Volatile Summary as of 19-FEB-2013 01:26:16
Node State Active Delay Circuit Next node
Links
13.5 (YELLOW)
Notice that the node YELLOW already exists, but with another number.
That cause an error when you try and set it.
You need to clear nodes where you see that error.
By the way, I could do a generic clear in the VMS command procedure, before starting the defines. Would people prefer that?
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
---
Filter service subscribers can train this email as spam or not-spam here: http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=76F0C5CA7A2C11E29…
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2013-02-19 09:24, G. wrote:
On Tue, 19 Feb 2013 08:49:52 +0100, you wrote:
NCP> copy known nodes from rullfs using permanent to volatile
Would that also work from MIM?
But other executor parameters would remain lost after a purge.
Just out of curiosity, which executor parameters would you loose with 'copy
known nodes'? We (Italian DECnet) usually do a 'copy known nodes from xxxxxx
using permanent to both with purge' and never noticed any problems (as long as
there are no "private" nodes locally defined and not registered into the node
we consider the authoritative database for node names).
You wouldn't loose anything, except for overwritten nodenames.
The executor parameters were lost because of my lazy DCL script writing. I had a "PURGE NODE * ALL" in there. Changed now...
The above works for VMS (at least down to V4.7); TOPS-10 has to be manually
updated; RSTS too; I do not remember about TOPS-20 any more: too much time has
passed since my last experiments with it.
Tops-10 and TOPS-20 are very similar.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2013-02-19 08:31, Ian McLaughlin wrote:
Perhaps the script needs a "CLEAR NODE *" at the beginning and a "SET KNOWN NODES *" at the end?
I've rewritten FIX.COM some, and now it should behave much better. Apologies for anyone who ran the first version and had his system messed up. I didn't think enough last night.
Johnny
Ian
On 2013-02-18, at 11:19 PM, Erik Olofsen <e.olofsen at xs4all.nl> wrote:
Johnny,
After the "define node"s in FIX.COM without "set node" I thought it would
be easiest to reboot, which gave errors reading the data base, and I think
this happened because the executor data had also been purged. After setting
the executor data, I could define all nodes.
Erik
On Tue, Feb 19, 2013 at 02:02:59AM +0100, Johnny Billquist wrote:
On 2013-02-19 01:48, Ian McLaughlin wrote:
Yes, I would like this. I assume that you are the authoritive list, so I have no need to keep any data on my end. A generic script that I can execute on the command line that clears and updates all in one would be great.
Ok. Done. For VMS users, just grab MIM::FIX.COM, and run it under DCL,
with appropriate privileges, and you'll have an up-to-date nodename
database.
Johnny
Thanks.
Ian
Sent from my iPad
On 2013-02-18, at 4:36 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2013-02-19 01:29, Johnny Billquist wrote:
On 2013-02-18 19:28, Ian McLaughlin wrote:
On 2013-02-18, at 10:19 AM, "Brian Schenkenberger, VAXman-"
<system at TMESIS.COM> wrote:
$ PIPE MCR NCP < FIX.CMD
When I do this, I get a bunch of errors like:
%NCP-W-INVPVA, Invalid parameter value , Name
Remote node = 32.5 (YELLOW)
Am I doing something wrong?
Nope. (This on a VMS box with a rather outdated nodename database):
$ mcr ncp
NCP>sho nod yellow
Node Volatile Summary as of 19-FEB-2013 01:26:09
Node State Active Delay Circuit Next node
Links
32.5 (YELLOW) ISA-0 1.13 (MIM)
NCP>tell mim sho nod yellow
Node Volatile Summary as of 19-FEB-2013 01:26:16
Node State Active Delay Circuit Next node
Links
13.5 (YELLOW)
Notice that the node YELLOW already exists, but with another number.
That cause an error when you try and set it.
You need to clear nodes where you see that error.
By the way, I could do a generic clear in the VMS command procedure, before starting the defines. Would people prefer that?
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
---
Filter service subscribers can train this email as spam or not-spam here: http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=76F0C5CA7A2C11E29…
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
---
Filter service subscribers can train this email as spam or not-spam here: http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=C40A12D47A6411E28…
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2013-02-19 08:19, Erik Olofsen wrote:
Johnny,
After the "define node"s in FIX.COM without "set node" I thought it would
be easiest to reboot, which gave errors reading the data base, and I think
this happened because the executor data had also been purged. After setting
the executor data, I could define all nodes.
Oh! Good point. I forgot about the volatile database. I'll fix that.
What happened with the executor data? What should I fix?
Johnny
Erik
On Tue, Feb 19, 2013 at 02:02:59AM +0100, Johnny Billquist wrote:
On 2013-02-19 01:48, Ian McLaughlin wrote:
Yes, I would like this. I assume that you are the authoritive list, so I have no need to keep any data on my end. A generic script that I can execute on the command line that clears and updates all in one would be great.
Ok. Done. For VMS users, just grab MIM::FIX.COM, and run it under DCL,
with appropriate privileges, and you'll have an up-to-date nodename
database.
Johnny
Thanks.
Ian
Sent from my iPad
On 2013-02-18, at 4:36 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2013-02-19 01:29, Johnny Billquist wrote:
On 2013-02-18 19:28, Ian McLaughlin wrote:
On 2013-02-18, at 10:19 AM, "Brian Schenkenberger, VAXman-"
<system at TMESIS.COM> wrote:
$ PIPE MCR NCP < FIX.CMD
When I do this, I get a bunch of errors like:
%NCP-W-INVPVA, Invalid parameter value , Name
Remote node = 32.5 (YELLOW)
Am I doing something wrong?
Nope. (This on a VMS box with a rather outdated nodename database):
$ mcr ncp
NCP>sho nod yellow
Node Volatile Summary as of 19-FEB-2013 01:26:09
Node State Active Delay Circuit Next node
Links
32.5 (YELLOW) ISA-0 1.13 (MIM)
NCP>tell mim sho nod yellow
Node Volatile Summary as of 19-FEB-2013 01:26:16
Node State Active Delay Circuit Next node
Links
13.5 (YELLOW)
Notice that the node YELLOW already exists, but with another number.
That cause an error when you try and set it.
You need to clear nodes where you see that error.
By the way, I could do a generic clear in the VMS command procedure, before starting the defines. Would people prefer that?
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
---
Filter service subscribers can train this email as spam or not-spam here: http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=76F0C5CA7A2C11E29…
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
I have a diskless node; the copy with purge command does purge the load
parameters of the remote node...
On Tue, Feb 19, 2013 at 10:32:46AM +0100, G. wrote:
On Tue, 19 Feb 2013 10:01:48 +0100, you wrote:
The executor node had also lost the routing type (area), after the NCP PURGE,
DEFINEs and reboot. If I execute a COPY command with "WITH PURGE", I get one
"component in wrong state message, probably when the executor node data is
going to be modified. This might explain it - do you see this message as well?
Yes, I get it too, and that's probably a side effect. Anyway, COPY was made
specifically for this task; I think it would never have been allowed to leave
DEC if it would have deleted/damaged the executor configuration. I think that
PURGE NODE * ALL is too "strong" in this context...
G. :)
