11 Apr
2023
11 Apr
'23
4:31 p.m.
On 2023-04-11 14:38, Paul Koning wrote:
I always thought of circuit names as more or less a suggestion, and certainly seeing
circuit names in Phase II reinforced that. The specs have them as ASCII strings, no
constraints (though TOPS-20 Phase II is severely constrained by implementation choice).
So the way to deal with circuit names is just that, as ASCII strings subject to the length
limit in the spec but not otherwise constrained.
In at least RSX, they are not just random, format free strings.
They are in the form dev-#, dev-#-# or dev-#-#.#. All which signify
things, and parts can be wildcarded.
For example, ethernet controllers have names like UNA-0, UNA-1 and so
on. Basically the controller (driver) name, followed by a number telling
which controller it is.
DDCMP lines have a form like DZ-0-0, which is DZ controller #0, line #0.
So you can also see DZ-1-7, for example.
Then you have multidrop lines, which have the form DZ-0-0.0, which is
controller 0, line 0, tributary 0.
My IP device have just one controller always, but can have multiple
lines. And you can set all circuits off with the command
NCP SET CIR IP-0-* STA OFF
for which NCP understand how to wildcard. And it's not just a simple
string wildcarding. Observe:
.ncp sho cir ip-0-*
Circuit summary as of 11-APR-23 16:29:24
Circuit = IP-0-0
State = On-starting
Circuit = IP-0-1
State = On
Adjacent node = 31.3 (PYRTR)
Circuit = IP-0-2
State = On
Adjacent node = 59.55 (KRYLBO)
Circuit = IP-0-3
State = On
Adjacent node = 1.15 (PONDUS)
Circuit = IP-0-4
State = On
Adjacent node = 1.860 (ER01RX)
Circuit = IP-0-5
State = On
Adjacent node = 29.2 (A29RT2)
Circuit = IP-0-6
State = On
Adjacent node = 1.840 (OLOF00)
Circuit = IP-0-7
State = On
Adjacent node = 62.637 (CTAKAH)
.ncp sho cir ip-*
NCP -- Show failed, invalid identification format, Circuit
And in RSX, all devices are max 3 characters. Same with VMS, if I
remember right. I have not checked if RSX might have some opinion of
it's more than 3 characters. But I have no idea what NETPTH might be
doing with circuit names, or how it process them, and if the problem is
there. I was just trying to guess based on some of the error messages
what it *might* be. :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Apr 10, 2023, at 9:09 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2023-04-11 03:04, Thomas DeBellis wrote:
PyDECnet is trying to follow the DECnet architecture specs closely (even to the point of
being struturally similar, something other implementations tend not to do).
Yes, I was catching up on that, but perhaps not
keeping up with it...
:-)
Seems unlikely that any code in netpth would be based on the behavior of PyDECnet, but
anyway, that detail will improve soon. So
what's the bottom line here? Is netpth rolling over and dying actually legitimate or
is there a better algorithm to use?
I don't think there any better algorithm. Why netpth throws errors is also unclear.
Maybe it has a more rigid idea on how circuit names should look? PyDECnet allows pretty
much anything as a circuit name. DEC was a bit more conservative... I think you need to
dig around on that maybe.