[HECnet] Effects of Rogue Duplicate HECnet Node?

[Thomas DeBellis]

You've put your finger on something that's puzzled me for quite some 
time about Tops-20's lexical implementation.

There is no standardized syntax in the generalized parsing interface 
(COMND% and GTJFN%) for using numeric node names. If you ask COMND% to 
parse a node name and do not shut off standard syntax, then you must 
specify a maximum six character word which conforms to the SIXBIT 
character set followed a double colon, which looks like what you would 
think it would, viz: VENTI2::

However, the integration into the monitor isn't as seamless as it 
appears to be under VMS.  In order to make a connection, you must build 
a special string for GTJFN% to swallow.  Let's suppose I wanted to grab 
the latest node list from MIM:: (which I do on a weekly basis); you 
would type MIM::FIX.T20;0 as the source to NFT. That's not what GTJFN% 
wants and you must transmogrify the string into DCN:MIM-FAL. Once that 
connection is open, you negotiate DAP and then ask MIM:: to send the file.

There is no standardized "[a.b.c.d]" syntax such as what you might use 
to get to an IP4 host which is neither in the DNS nor host tables.  You 
can use COMND% to parse for a number optionally followed by a dot and 
another number and the operator NICE interface (NCP) does in fact do 
this.  Indeed, it is the only interface besides SETNOD which does this 
(in order to define nodes).  So I can give an area.address to NCP as an 
argument to a TELL verb in order to get remote information.

Neither programs will work right for the general user.  The user could 
use COMND% to parse for the numbers and then use the .NDRNM function of 
the NODE% JSYS to convert them into a name which is palatable to GTJFN%. 
However—and this is the point—if that name isn't in Tops-20's node data 
base, then the NODE% JSYS will fail and you have nothing to give to 
GTJFN%. Therefore there is no way for a general user to make a connection.

I can't make up my mind as to whether this is a bug, a misfeature or 
unfinished business.  Tops-20 installations had millions of (1980's) 
dollars hardware and software, trained staffs and often large 
populations.  Management of them was very different from a lab machine 
(PDP-8, PDP-11) or departmental machine (VAX 11/780). At least in the 
university setting, students are an inquisitive lot and a lot of had to 
be done to prevent certain kinds of activities, probing and downright 
meddling.  It seems to me that not defining the node in the first place 
on an academic machine is a great misfeature as it eliminates probing.

However, as I've said before (viz., the NFT: device and FTS), there are 
parts of Tops-20 DECnet that strike me as not fully productized.  One 
example is that there is no way for /anybody/ to extract the area and 
number of a node once it is the monitor.  You can (and should) verify 
that the node is 'legitimate' by using .NDVFY function of the NODE% 
JSYS, which will also tell you some interesting things about it.  
However, it will not divulge the aforementioned numbers.  It annoyed me 
enough so that I modified the monitor to do just that with an additional 
function, .NDVFX and I use this in DAP (but don't depend on it) and in 
the mailer (where I do).

I haven't posted the changes anywhere because I can't make up my mind 
whether this was fixing an oversight or breaking a design decision or 
indeed, whether that should even matter.

Another example is that, once a node is inserted into the monitor data 
base, there is *no* documented way to remove it.  As I was implementing 
.NDVFX, I was looking at the in-area hashing code and noticed that it 
appears that the monitor will remove a node marked as -1 (36 bits).  I 
have yet to test this.  Certainly SETNOD gives no hint (another reason 
I'm toying with a rewrite).

Curiouser and curiouser.  Do the above two functionalities exist in 
other operating systems?
> ------------------------------------------------------------------------
> On 3/3/20 2:16 PM, Paul Koning wrote:
>
> Interesting.  It depends on the application API.  For example, in RSTS the "node name" argument can contain a number in string form, which lets you connect by address.  But in some places in NCP things don't work if there isn't a name for the node.  I would call that a bug.
>
>> ------------------------------------------------------------------------
>> On Mar 3, 2020, at 1:13 PM, Thomas DeBellis <tommytimesharing at gmail.com> wrote:
>>
>> You may be talking about a number of things here.  DECnet node numbers are something (very) vaguely like IP tuples, except with half the bits and fixed fields.  The upper 6 bits constitute the area, the lower 10 bits constitute the number within area.  This is what I recall:
>>
>> 	• If the node number's name is not defined to other systems, then many user level programs will not be able to see if.  Tops-20 won't able to build a connection.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20200303/dd816117/attachment.html>