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