[HECnet] Re: NETPTH Messages

On Apr 11, 2023, at 1:00 PM, Thomas DeBellis &lt;tommytimesharing(a)gmail.com&gt; 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: [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 I ran a few tests looking for various PyDECnet versions and their responses to a SHOW NODE xxx:: STATUS, viz: 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: [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 So what is this? A newer version of PyDECnet isn't 'doing the right thing'?