In reverse order, I think the numeric-only concern is addressed easily enough, assuming you think your own local executor's node data base is up to date.
This is more or less the case on TOMMYT:: and VENTI2::, which download the latest and greatest from MIM:: on a weekly basis and then use my SETNODE rewrite to compute the set difference between the current and new definitions in order to change as little as possible in the monitor's volatile storage.
In short, if the remote node doesn't know, try recovering by
asking the local executor. That seems straightforward.
On 4/11/23 2:01 PM, Paul Koning wrote:I didn't realize that. T1.1 will report next node if it's in the same area or if it's adjacent. It should do so also if it's in a different area, and I have coded that fix.
The "numeric only" happens if the node number in question isn't in the node name database of that particular node.
paul
On Apr 11, 2023, at 1:00 PM, Thomas DeBellis <tommytimesharing@gmail.com> wrote:
Regarding its performance, I don't think netpth was ever a candidate for full productization, apparently being more of an internal tool for DECnet specialists. However, this is only a guess.
From the edit history, it looks like it started out life in 1982 being put together by Stu Grossman, who I thought was working on Stanford at the time. That would be surprising as I had thought Stanford didn't run Tops-10. But maybe I'm wrong on both counts. It then appears to have been adopted by Bill Davenport, Gunnar Lindell and Carl Appellof. I don't know about Bill or Gunnar, but I'm pretty sure I remember Carl being at DEC.
I would guess netpth was part of a Tops-10 SWSKIT and was then partially ported to Tops-20. It only uses those Tops-20 JSYi that are necessary to do its job. Since Phase IV DECnet on the PDP-10 was first developed under Tops-10 (where it could run in user mode) and then ported to Tops-20 (it's all under conditional assembly), the API's are remarkably similar. What I mean by that is the Tops-10 UUO and Tops-20 JSYS calling interface are nearly plug compatible with the exception of the UUO having more flexible register scheduling.
So, I think the crashing is due to error conditions that weren't anticipated in those early days, that is, that you would never not get told what the adjacent nodes were. It is also not impossible that some of the fixes that I put into Tops-20 to report secondary error conditions could be triggering this.
I do remember netpth working at some point, Peter Lothberg demonstrated it about a year and a half ago on 10/21/21, viz:
I ran a few tests looking for various PyDECnet versions and their responses to a SHOW NODE xxx:: STATUS, viz:[Routing path from MRC (59.41) to LEGATO (2.1)] From Via Back Thru Cost Hops MRC (59.41) =>NI-0-0 / TAP-0 <= OPS1VA (59.59) -1 -1 OPS1VA (59.59) =>GRE-3 / GRE-4 <= IAD2 (59.1020) -1 -1 IAD2 (59.1020) =>DMC-0 / MUL-59-1020 <= A2RTR (2.1023) -1 -1 A2RTR (2.1023) =>TAP-0 / QNA-1 <= LEGATO (2.1) -1 -1
Node
PyDECnet Version
Next Node?
A2RTR::
V1.0-596
Yes
PYRTR::
T1.1-640
No
STORTR::
*** Not Reported ***
Yes (Numeric, Only)
DEC000::
V1.0-583
No
NOVA::
V1.0-596
Yes
A29RT2::
T1.1-648
No
This suggested running a test through the older versions, which worked, viz:
So what is this? A newer version of PyDECnet isn't 'doing the right thing'?[Routing path from VENTI2 (2.522) to SAMV02 (2.152)] From Via Back Thru Cost Hops VENTI2 (2.522) =>NI-0-0 / BRG-0 <= A2RTR (2.1023) 10 3 A2RTR (2.1023) =>MUL-2-150 / MUL-1 <= SAMISH (2.199) 9 2 SAMISH (2.199) =>ETH-0 / UNA-0 <= SAMV02 (2.152) 4 1