[HECnet] DEfining HECnet node names on TOPS-10

[Thomas DeBellis]

/What??/

Case?!  Order?!  Abbreviations?!  What the heck is this? /Real/ programs 
don't care about any of that!

The return was necessary because Tops-20 DEC standard SETNOD would 
gracefully signal end-of-input file by going into an endless loop.  It 
would also be appropriate in OPR if you did an ENTER NCP, first and then 
end-of-file file would put you back into the main OPR parse level.  The 
formats are similar enough that they could be parsed by OPR for the 
volatile definitions and SETNOD for for the permanent ones.

However, if you used the text file on boot, that would probably slow 
down system availability by about 5 to 10 seconds (if you were waiting 
on Galaxy to set logins).  Galaxy has a bunch of stuff to do before its 
ready for OPR. These commands then have to be parsed by OPR using COMND% 
which is not that efficient, then sent via IPCF% to Orion, when then has 
to IPCF% NML. Not fast...

I can really only think of one reason to order the node file, but it is 
neither by name or number.  While the binary file is loaded into the 
monitor with one NODE% JSYS, the monitor does not load it in the order I 
write it.  The internal monitor tables are hash based.

If you reverse engineer the hashing algorithm and you look at the 
instruction paths, then maybe (/maybe/) you could optimally order the 
binary file to minimize the impact of certain clash operations on load.  
For some bizarre reason, I haven't asked Johnny to sort the text file in 
hash order...

------------------------------------------------------------------------
On 11/15/21 5:26 PM, Robert Armstrong wrote:
>> A problem of case? I can change it all to uppercase if that helps...
>    .. and also don't abbreviate ("NODE" not "NOD").  The "RETURN" at the end is also not needed, although NODNAM will ignore that.
>
> Bob
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20211115/5bb474e9/attachment.htm>