11 Apr
2023
11 Apr
'23
5:14 p.m.
On 2023-04-11 16:42, Paul Koning wrote:
Well, controllers like ethernet usually are in the form dev-#. They
don't have multiple lines in the way a serial controller do.
On Apr 11, 2023, at 10:31 AM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2023-04-11 14:38, Paul Koning wrote:
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.
Indeed, for any given implementation there are patterns and they are followed
semi-consistently across implementations. But the architecture spec has no rules other
than that circuit and line names are "id-string". The only place I see the
dev-# type format mentioned isn't for the names but rather for the value of line
attribute "device". On Apr
10, 2023, at 9:09 PM, Johnny Billquist <bqt(a)softjar.se> wrote:
On 2023-04-11 03:04, Thomas DeBellis wrote:
> 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.
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).
> 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.
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. Also, even when an implementation follows the RSX
pattern, the actual names used may vary. For example, async DDCMP on RSTS uses circuit
names of the form TT-# no matter what controller type is involved.
Oh. I was definitely not trying to imply that there are any specific
names used on the dev part. That is clearly a string that might be
whatever. It might possibly have some length limit, and I don't think
anything but letters are allowed. But that's about it.
It gets worse when you consider Phase II, where
circuit names contain underscores rather than hyphens. So for an application that reads
circuit and node info from other implementations, the rule I would suggest is to assume
nothing about the structure of circuit names.
Underscores might be an interesting thing to investigate. But I'm not
going down that rabbit hole right now.
I'm merely suggesting that maybe NETPTH, or TOPS might have some
additional constraints on circuit names, which is why Thomas got some of
his errors...
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