At least for what would be a typical hobby configuration for a KL
based system, Tops-20 doesn't care how specific you get, NI-0 and
NI-0-0 basically getting you the same thing, viz:
NCP>show liNE ni-0 13:53:29 NCP Request # 1104; Show Line Summary Completed Line = NI-0 State = On NCP>show line ni-0-0 13:53:37 NCP Request # 1105; Show Line Summary Completed Line = NI-0-0 State = On NCP>
I think what would really be necessary to know would be to have
access to a connected (PDP-11 based) DN20 (running MCB), which is
where actual DDCMP lines would be found. The DTE interface on
KLH10 does not simulate this, but I think some work may have been
done as a Chaosnet implementation appears to be simulating what
MIT did, repurpose a DN20 with special code, the Ethernet adapter
being in the DN20.
What I recall is that you needed the final -x
for lines or controllers that could handle multiple lines. I
believe a KMC would do that, but I honestly don't remember.
The source for Tops-20/Tops-10 Phase IV NICE is written in BLISS,
so I don't know how finicky it would be about what's in the
string.
I keep daydreaming about taking the Phase II NICE, which I do have, and updating it for Phase IV. This would be a lot of work, so I haven't really looked into the matter. If I did, then I would use full COMND% parsing to get recognition on the line types, DMR, NI, CI, KMC, Etc. That might be a fantasy as I would imagine these were never standardized.
In that case, I could parse for either a dash or underscore as a separator in the event of talking to a Phase II node. If I had awareness of what was running, then the parse options can be changed on the fly. I do this all over the place in other programs and it's really nice to have a program tell you what it's expecting based on the actual environment instead of what's possible.
For example, for the executor node, I could issue a SHOW KNOWN LINES and parse that for the
line type prefixes and have awareness for that node, allowing
escape recognition.
I do think being able to wildcard and match lines like what RSX
does would be a fine feature. Another thing that makes me want to
roll up my sleeves and dive into a NICE rewrite.
On 4/11/23 1:51 PM, Paul Koning wrote:On Apr 11, 2023, at 11:14 AM, Johnny Billquist <bqt@softjar.se> wrote: On 2023-04-11 16:42, Paul Koning wrote:On Apr 11, 2023, at 10:31 AM, Johnny Billquist <bqt@softjar.se> wrote: ... 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".Well, controllers like ethernet usually are in the form dev-#. They don't have multiple lines in the way a serial controller do.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.The network management architecture spec says: " ...id-string consists of one to sixteen characters from the set of upper-case alphabetics, numerics, period and hyphen. An id-string must contain at least one alphabetic character." Most names, including circuit, line, and module names are "id-string".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.Phase II NICE has two different encodings for line names: ASCII string which seems to be pretty much unconstrained, and a compact coded form consisting of a device code, controller number, and optional line number. TOPS-20 only implements the latter, it seems. And the text representation shown for that second form is dev_# for line 0, dev_#_# for non-zero line numbers. There is a short list of defined device codes, so if a node wants to tell TOPS-20 that it has a line named ETH-0, it can't do that. paul _______________________________________________ HECnet mailing list -- hecnet@lists.dfupdate.se To unsubscribe send an email to hecnet-leave@lists.dfupdate.se