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

[Thomas DeBellis]

Ha!  You can't find it if it isn't in there!  Tricky, eh?

I am not sure why Tops-20 has this kind of 'split' personality (if you 
want to call it that), that permanent and volatile stores are in 
entirely different programs with different interfaces.  But it seems to 
me that you were looking precisely where you should have been looking; 
for the Tops-20 NCP to be compliant, it should do this.

I can only guess that they explicitly chose not to implement completely 
functional persistent store and that this was not an oversight.  You 
have to exert effort to get that right so it will exist across crashes.  
And then NCP was changing, so whatever structures you created, you would 
probably need to change.

On the other hand, a great deal of effort seems to have been expended 
elsewhere in the Phase IV effort; some really clean well thought out 
code in ROUTER, D36COM, Etc.

On 11/11/21 6:22 PM, Johnny Billquist wrote:
> I must admit that I hadn't considered the possibility of just saving 
> the core. Which of course can accomplish the same thing in a neat way.
>
> I was just hunting around in NCP in TOPS-20, and never found there how 
> to configure something that would stick around after a boot, like you 
> have on other systems...
>
> Just shows how (in)experienced I am at TOPS-20. :-)
>
>   Johnny
>
> On 2021-11-11 23:27, Thomas DeBellis wrote:
>> 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
>>>>>
>>>
>