[HECnet] RSTS/E started emitting "?EVTLOG (BLDNIC) -- %Integer error" messages

[Thomas DeBellis]

Hmm, if I'm understanding you correctly, then I'm not sure I would agree 
with you, 100%.  Recall the binary file I build?  This is dumped 
/directly/ into the monitor on reboot, there is no re-parse of the .T20 
file; that only ever gets looked at precisely once.

21:05:28 USER   SETNODE>*Save /NO-ACCESS /RESTRICTED
21:05:28 USER
21:05:28 USER   [Fork SETND2 opening ? for writing restricted]
21:05:28 USER   [Saving to binary file: *TOMMYT:<SYSTEM>NODE-DATA.BIN.1 
*;PROCESS-ONLY-JFN:2 ;RD ;WR ;BSZ:36 ]

This resulting .BIN file is ⅓ the size of the .T20 file and goes into 
the monitor with a single NODE% JSYS, so there is only a single context 
switch.  The monitor does some validation of the entries before putting 
them into the hash table.  Naturally, I can also read the binary file 
and reconstruct the text file:

SETNODE>GET (binary node definition file) 
*SYSTEM:NODE-DATA.BIN*/no-ACCESS /pagE-MAP /unrESTRICTED-READ /prelOAD
Mapped 4 pages, 1830 Words, 915 Nodes.
SETNODE>RECONSTRUCT (node keyword tables from binary table) /silENT
[Closed log file: NUL:]

I think the only faster way to do this would be to save the Monitor's 
volatile hash table directly to disk and read it back in on reboot.  If 
you check it as you read, then you might be back down to the .BIN file 
input speeds, which are clearly faster than doing the parse of the .T20 
file; a lot faster. If you don't check then you might not be able to 
boot if it gets funny data in it.  Or maybe you could do minimal checking.

However, I do think that the idea of a seperate volatile and permanent 
database is a very good idea.  You could do that with my SETNODE 
rewrite, but /only/ if /nothing/ else was touching either node store 
(like a remote NCP).  I think the other implementations are probably far 
cleaner in this regard.

------------------------------------------------------------------------
On 11/11/21 4:59 PM, Johnny Billquist wrote:
> This is actually one thing I've found annoying with TOPS-20.
>
> With VMS, as well as PDP-11 OSes, you have both a volatile and a 
> permanent database.
>
> For the volatile db, the commands are:
> SET
> CLEAR
> SHOW
>
> For the permanent db, the commands are:
> DEFINE
> PURGE
> LIST
>
> Exactly the same syntax and everything, but one affects what you have 
> right now, and the other only affects what is stored permanently, and 
> is used when the system starts to populate the volatile db.
>
> With TOPS-20 seems you always have to run through the definitions when 
> you boot.
>
>   Johnny
>
> On 2021-11-11 21:56, Thomas DeBellis wrote:
>> So /that's/ the difference between SET and DEFINE?  Gee, that's 
>> deluxe! What a great idea!
>>
>> If you will look at my previous batch log, you will see that I only 
>> update the running system node database with the set difference from 
>> the previous week's node file.
>>
>> There is no way to 'restart' DECnet on Tops-20 without a reboot.  
>> Once you set certain items and the Executor starts, that's it for the 
>> run of the operating system. Further, there are no NODE% functions to 
>> either purge the entire running database nor retrieve it into user 
>> memory, which keeps striking me as perhaps an arbitrary limitation.
>>
>> On the other hand, unless I am doing monitor development, I never 
>> have any reason to reboot and rarely crash, so the difference would 
>> be largely moot to me, absent renaming or renaming the local 
>> Executor.  Right now, TOMMY ('Production') is up over 7,171 hours 
>> while VENTI2 (active development) is up over 3,428 hours.
>> ------------------------------------------------------------------------
>> On 11/11/21 9:09 AM, Paul Koning wrote:
>>>
>>>
>>>> On Nov 11, 2021, at 8:36 AM, Supratim Sanyal <supratim at riseup.net> 
>>>> wrote:
>>>>
>>>> On 11/11/21 3:53 AM, Johnny Billquist wrote:
>>>>
>>>>> If a specific format is needed for RSTS/E nodes, I can create that 
>>>>> format file whenever the nodename database is updated. Just let me 
>>>>> know what the format should be.
>>>>>
>>>> $ type defnod.cmd
>>>> *SET VER**
>>>> **SET NOON**
>>>> **NCP DEFINE NODE 1.1 NAME MAGICA**
>>>> **NCP DEFINE NODE 1.2 NAME ERNIE**
>>>> **NCP DEFINE NODE 1.3 NAME FNATTE**
>>>> **...**
>>>> **...**
>>>> **NCP DEFINE NODE 62.637 NAME CTAKAH**
>>>> **NCP SET NODE 1.1 NAME MAGICA**
>>>> **NCP SET NODE 1.2 NAME ERNIE**
>>>> **NCP SET NODE 1.3 NAME FNATTE**
>>>> **...**
>>>> **...**
>>>> **NCP SET NODE 62.637 NAME CTAKAH*
>>>>
>>> The "set" commands are a nice additional item but the define 
>>> commands are the important part.  If you include the set commands 
>>> the running system is updated at that time; if you leave them out, 
>>> it will be up to date at the next DECnet restart.
>>>
>>> paul
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20211111/0f2f1c9b/attachment.htm>