6 Jul
2019
6 Jul
'19
1:57 a.m.
On Jul 5, 2019, at 6:57 PM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2019-07-06 00:22, John Forecast wrote:
Right. NETACP isn't running when DECnet starts. But no lines are running when DECnet
have started either. That comes as a separate step which can be done at any time later in
life, and you can turn lines both on and off.
But I should admit that I right now can't remember off the top of my head if I
actually remember details here, or if I'm just guessing.
I had to write a driver for DECnet, which forced me to seriously dig into the internals,
but it's been a couple of years since now.
I had to go back and look myself - it?s been almost 40 years!
On Jul 5,
2019, at 5:51 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2019-07-05 23:31, John Forecast wrote:
NETACP isn?t even running when DECnet starts loading. CEXBF.MAC is compiled with
the M+ kernel but in earlier versions it was distributed with the DECnet kit and loaded
into memory by ?NCP SET SYS?. NTINIT reads CETAB.TSK I think and then kicks off NTL to
load each CEX module into memory. If you look at the .DAT file for a particular module
you?ll see it?s in a limited assembler syntax. NTL has a mini assembler/linker included to
hook modules and drivers into CEX and the interrupt system. > On Jul 5, 2019, at 3:29 PM, Johnny Billquist
<bqt at softjar.se> wrote:
>
> 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.
>
The split between the DECnet device driver and NETACP is mostly around performance - the
driver handles data transmit and receive while NETACP handles the slower
connect/disconnect logic. Doing it this way allowed us to overlay NETACP on unmapped 11M
systems and save some physical memory (shudder!!).
Well, the device driver is split between the code running in interrupt context, which
obviously isn't properly within NETACP, and the code running in a non-interrupt
context, which is running under NETACP.
The whole set of CEX services are available, and NETACP is also responsible for the
synchronization between the different driver and other levels.
The whole installation of drivers, and linkage into the interrupt system is established
by NETACP, unless I remember wrong.
CEXBF.MAC is a module in the kernel to get access to
various CEX services without having to bother where they really are, which is related to
the whole think of vectored tasks in M+. But the routines in CEXBF.MAC, as far as I can
remember, essentially only queues packets into the appropriate queues for a module, and
then kicks off NETACP, to actually schedule execution in the module to process things. Or
else directly steps into that
What you see in CEXBF.MAC is all there ever was for CEX. When I joined the development
team in Jan ?77, an implementation of Phase II NSP was running standalone under a
?Communications Executive?. The decision was made to ?port? this ?Communications
Executive? into each of the RSX-11 Decnet implementation (11M/11S/11D and IAS) and they
would all use this NSP implementation. As a side benefit we would get all the device
drivers that had been implemented as well.
module to perform the service, but then it should be
done by another module in CEX, so it all happens in the context of NETACP in the end.
Essentially, when we talk about line drivers, they are either called by LLC or DLC modules
running in NETACP context, or else in interrupt, in which case it queues packets to a DLC
or LLC, which is asynchronous, and that module will then again be scheduled in NETACP.
No, that would be too expensive if every packet had to flow through NETACP. When a
packet is queued to a process (asynchronous rather than direct call) it is queued to the
NS: fork block. When NS: driver runs as a result it peeks at the request and may queue it
to NETACP or process it immediately.
I guess (I haven't actually written any modules
running under anything else than M+) that for other systems, you instead just have to link
including NETACP.STB, to directly have the address of the routines instead. And any
change/update means you'd have to relink your modules for CEX.
Yes, CETAB.MAC is used as a source of all configuration information, and a compiled
version is used for some parts in there.
Now I think about it some more, I think NTINIT gets its information from CETAB.MAC rather
than CETAB.TSK so it get up to date information.
But you should probably know all this in way more
detail than I do. Your name is, after all, in the sources. :-)
True, but it?s been a long time!
John.
> 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.
>
Don?t forget VNP which allows NCP setup commands to be applied to the saved image so that
they will take effect the next time the system is booted.
Didn't want to make it sound even more complex. :-)
John.
> Johnny
>
>> John.
>>> 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
>
>
> --
> 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
--
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