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

[Johnny Billquist]

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
>>>>
>>

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol