11 Nov
2021
11 Nov
'21
11:27 p.m.
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
>