[HECnet] Anonymous FAL (Tops-20)

[Johnny Billquist]

I've been managing TOPS-20 as well, so I know about OPR and so on.

However, I don't know much the internals at all.

In RSX, NCP is the program which is the user interface part. But all NCP 
does is it establish a DECnet connection to NICE, in order to perform 
any operations.

So there are no other type of interprocess communication going on with 
regards to DECnet in RSX. But in general, there are a mechanism for 
sending messages between tasks in RSX.

But DECnet is handled, as mentioned, by NETACP. NETACP in turn will 
start other tasks as needed when connection requests arrive.

You cannot change the DECnet address under RSX either. In fact, you can 
not even change it once on the running system. The only way to change it 
is to change the permanent database and reboot in order for it to take 
effect.

And in RSX, modifying the permanent database is not done with NCP but 
with a different task called CFE. However, in VMS, NCP are used for both 
databases.

   Johnny

On 2019-07-05 20:57, Thomas DeBellis wrote:
> Yes and No.  Some of the design concepts are quite similar which is 
> unsurprising.
> 
> The NICE task on Tops-20 has a named object called NCU.  The (fork) 
> listener is NMLT20 which will also accept local (and cluster) IPCF% 
> communications.  In OPR, you enter NCP submode, which parses nearly the 
> exact same command set as NCPACP.   It then (via Orion) sends this to 
> NMLT20 which performs the action (or crashes) or sends it to another NCU 
> (or crashes).
> 
> So that sounds analogous to NCPACP to NICE.TSK architecture. Remind me 
> how RSX does the inter-task communication?  I haven't programmed it 
> since 1977...  I remember it being different from IPCF%, but still 
> thought it was neat.
> 
> There is no permanent store in Tops-20 for this DECnet information.  It 
> is scattered through various configuration files that are swallowed 
> depending on criticality during boot up an operation.  Tops-20 does 
> *not* like having either the MAC address nor the local DECnet node 
> number numbers changed, ever and configuration for router and local area 
> must be done 'early' and once only; so all that stuff is in 
> SYSTEM:7-1-CONFIG.CMD.  You have to reboot to get changes updated.
> 
> Other stuff (like setting the executor identification) and enabling 
> services goes into SYSTEM:SYSTEM.CMD where OPR hands it to NMLT20.
> 
> There is much to be learned by comparing the architectures.
> 
>> ------------------------------------------------------------------------
>> On 7/4/2019 2:37 PM, Johnny Billquist wrote:
>>
>> NETACP in RSX (and I suspect VMS) is just the process/program that 
>> implements a lot of the DECnet protocols. It is actually pretty much 
>> not related to anything here.
>>
>> At least in RSX, the NICE protocol is handled by a separate task 
>> called NICE.TSK.
>>
>> And when you run NCP under RSX, it pretty much talks to NICE for any 
>> operations requested, also for the local node.
>>
>> I know that this is very different from how things work under TOPS-20. 
>> There are no handling of objects from NCP using NICE in TOPS-20, and 
>> there is no permanent database (as far as I know), compared to RSX or 
>> VMS.
>>
>>   Johnny
>>> ------------------------------------------------------------------------
>>> On 2019-07-04 03:06, Thomas DeBellis wrote:
>>>
>>> Tops-20 has a subtly different architecture, in part perhaps 
>>> reflective of the previously described 'bolt on'.
>>>
>>> The closest thing to NETACP is NMLT20, which implments NCU. Parts of 
>>> that are in written BLISS and at one point, it had a shared a partly 
>>> common code base with some RSX/VAX stuff. Interfacing to Galaxy (the 
>>> Tops-10/Tops-20 Operator Interface and Queuing system), NMLT20 was 
>>> /notorious/ for crashing in early (Phase III) releases.  I wrote many 
>>> SPR's...
>>>
>>> I can't define objects. FAL itself puts up the FAL object and speaks 
>>> DAP over it.  Communication with it is either over a DECnet FAL 
>>> object (via DAP) or with Tops-20 IPCF.  The only messages that gets 
>>> are (the largely useless) logging messages from inferior FAL 
>>> processes and checkpoint messages from Quasar, the queue manager.  It 
>>> doesn't process any other messages from Galaxy, so it doesn't seem 
>>> that it would know how to swallow anything that NMLT20 might hand off.
>>>
>>> I can define the following:
>>>
>>>     CIRCUIT
>>>     EXECUTOR
>>>     KNOWN
>>>     LINE
>>>     LOGGING
>>>     MODULE
>>>     NODE
>>>
>>> I'll see what I turn up when I finish polishing off that pesky DAP 
>>> bug (after I finish the VIKING OCR).
>>>
>>> Lots for you to look forward when you get back into it, eh? :-D
>>>> ------------------------------------------------------------------------
>>>> On 7/3/2019 5:34 PM, Robert Armstrong wrote:
>>>>
>>>> > I'll have a look at FAL; at first glance it has no hooks for a 
>>>> default account
>>>>
>>>> It’s probably handled by NETACP, or whatever passes for that on 
>>>> TOPS20.  Does your NCP understand the command
>>>>
>>>> DEFINE OBJECT FAL USER <whatever> PASSWORD <whatever>
>>>>
>>>> Bob
>>>>
>>
>>


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