On 1/7/2013 3:14 PM, Brian Schenkenberger, VAXman- wrote:
Brian Hechinger <wonko at 4amlunch.net> writes:
On 1/7/2013 2:48 PM, Brian Schenkenberger, VAXman- wrote: > Brian
Hechinger <wonko at 4amlunch.net> writes: > >> What exactly does that mean?
Did any other messages (codes) accompany the error? >
None that I noticed, but they could have been masked by this code.
Just doing NCP TELL to other machines on hecnet.
Did you get kicked back to DCL? If so, before entring any other command
at the DCL prompt, issue: $ SHOW SYMBOL $STATUS.
Probably? This is all being doing from python. I can try to have it run that, but i think i will get a new process space so it won't matter.
-brian
On 1/7/2013 3:14 PM, Steve Davidson wrote:
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Brian Hechinger
Sent: Monday, January 07, 2013 15:10
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] NCP-F-NETIO
On 1/7/2013 2:48 PM, Brian Schenkenberger, VAXman- wrote:
Brian Hechinger <wonko at 4amlunch.net> writes:
What exactly does that mean?
Did any other messages (codes) accompany the error?
None that I noticed, but they could have been masked by this code.
Just doing NCP TELL to other machines on hecnet.
-brian
If you are tying this against GORVAX::, or PLUTO::, you will probably
not have much success. GORVAX::'s connection to the bridge is going up
and down every minute or so, and PLUTO:: is having issues with buffer
availability. SIGH...
-Steve
I bet that's what it is then.
-brian
Brian Hechinger <wonko at 4amlunch.net> writes:
On 1/7/2013 2:48 PM, Brian Schenkenberger, VAXman- wrote: > Brian
Hechinger <wonko at 4amlunch.net> writes: > >> What exactly does that mean?
Did any other messages (codes) accompany the error? >
None that I noticed, but they could have been masked by this code.
Just doing NCP TELL to other machines on hecnet.
Did you get kicked back to DCL? If so, before entring any other command
at the DCL prompt, issue: $ SHOW SYMBOL $STATUS.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Brian Hechinger
Sent: Monday, January 07, 2013 15:10
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] NCP-F-NETIO
On 1/7/2013 2:48 PM, Brian Schenkenberger, VAXman- wrote:
Brian Hechinger <wonko at 4amlunch.net> writes:
What exactly does that mean?
Did any other messages (codes) accompany the error?
None that I noticed, but they could have been masked by this code.
Just doing NCP TELL to other machines on hecnet.
-brian
If you are tying this against GORVAX::, or PLUTO::, you will probably
not have much success. GORVAX::'s connection to the bridge is going up
and down every minute or so, and PLUTO:: is having issues with buffer
availability. SIGH...
-Steve
On 1/7/2013 2:40 PM, Brian Schenkenberger, VAXman- wrote:
Brian Hechinger <wonko at 4amlunch.net> writes:
On 1/7/2013 2:15 PM, Brian Schenkenberger, VAXman- wrote: > Brian
Hechinger <wonko at 4amlunch.net> writes: > >> Because the one downside of
the Cisco's is they don't speak NICE. It >> would be awesome if they
did. > That's because they speak IOS! :P >
No, they *run* IOS. They *speak* many, many different things. :)
My DTC01s and DTC03s can *speak" many many different things too! ;)
Yes, but what do they *run*? :)
-brian
On 1/7/2013 2:48 PM, Brian Schenkenberger, VAXman- wrote:
Brian Hechinger <wonko at 4amlunch.net> writes:
What exactly does that mean?
Did any other messages (codes) accompany the error?
None that I noticed, but they could have been masked by this code.
Just doing NCP TELL to other machines on hecnet.
-brian
Sure... Just one more example of PMR! :-)
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Ian McLaughlin
Sent: Monday, January 07, 2013 14:49
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Area 48.....
Sounds like bang-path routing from the good-old-days of UUCP.
Ian
On 2013-01-07, at 11:41 AM, "Steve Davidson" <jeep at scshome.net> wrote:
When DEC began to run out of node names/addresses (64512) they
resorted to something called hidden areas. "Spitbrook Rd" (Nashua,
NH) had nodes that were in areas 61-63 that could not be
seen beyond that facility.
Other sites, like the "The Mill" and "Parker Street" (Maynard, MA)
also reused those same addresses just not the node names.
If the node
you were on was in a hidden area then you had to do your
own "routing"
of sorts to get the areas outside your facility.
As an example: If I was on node FOO::, and FOO:: was in a hidden
area, and I wanted to send email to another site on node BAR:: then
the DECnet path might look something like this:
ROUTR1::BAR::<username>. Where ROUTR1:: is a non-hidden area node
within my facility.
If the other end had the same issue then the chosen path might look
something like:
ROUTR2::FOO::DAVIDSON. Where ROUTR2:: is a non-hidden area node
within the source facility.
This was referred to as PMR (Poor Mans Routing). The
concept was not
new because it had been used in previous versions of DECnet anyway,
the application was... Sort of... HECnet has reserved area 63 for
hidden area nodes - to play with mostly. I did some
playing around last year.
If I can ever find my notes (from DEC days) about the whole setup I
will get back to playing some more with it.
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Brian Hechinger
Sent: Monday, January 07, 2013 14:44
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Area 48.....
On 1/7/2013 2:41 PM, Steve Davidson wrote:
This was referred to as PMR (Poor Mans Routing). The
concept was not
new because it had been used in previous versions of DECnet anyway,
the application was... Sort of... HECnet has reserved area 63 for
hidden area nodes - to play with mostly. I did some
playing around last year.
If I can ever find my notes (from DEC days) about the whole setup I
will get back to playing some more with it.
This sounds like it was a bad idea back then and a bad idea now. :)
-brian
Actually, it worked quite well! In my group most people that had
hidden area nodes also had accounts on non-hidden area clusters so most
of their email was fine. In fact, cluster aliases had to be non-hidden
so it all just worked out.
I remember using "mail", "phone", and "notes" without issues.
-Steve
Sounds like bang-path routing from the good-old-days of UUCP.
Ian
On 2013-01-07, at 11:41 AM, "Steve Davidson" <jeep at scshome.net> wrote:
When DEC began to run out of node names/addresses (64512) they resorted
to something called hidden areas. "Spitbrook Rd" (Nashua, NH) had nodes
that were in areas 61-63 that could not be seen beyond that facility.
Other sites, like the "The Mill" and "Parker Street" (Maynard, MA) also
reused those same addresses just not the node names. If the node you
were on was in a hidden area then you had to do your own "routing" of
sorts to get the areas outside your facility.
As an example: If I was on node FOO::, and FOO:: was in a hidden area,
and I wanted to send email to another site on node BAR:: then the DECnet
path might look something like this:
ROUTR1::BAR::<username>. Where ROUTR1:: is a non-hidden area node
within my facility.
If the other end had the same issue then the chosen path might look
something like:
ROUTR2::FOO::DAVIDSON. Where ROUTR2:: is a non-hidden area node within
the source facility.
This was referred to as PMR (Poor Mans Routing). The concept was not
new because it had been used in previous versions of DECnet anyway, the
application was... Sort of... HECnet has reserved area 63 for hidden
area nodes - to play with mostly. I did some playing around last year.
If I can ever find my notes (from DEC days) about the whole setup I will
get back to playing some more with it.
Brian Hechinger <wonko at 4amlunch.net> writes:
What exactly does that mean?
I just too a look at the NCP sources. It appears that that message is
returned when several $QIOs fail. Sadly, the code masks the $QIO(W)'s
return status and anything in the $QIO(W)'s IOSB.
Perhaps, if you can describe what you were doing when you reveived the
error, the cause can be narrowed down.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
