[HECnet] Intermittent Connection with PyDECnet?
Johnny Billquist
bqt at softjar.se
Mon Mar 2 17:21:51 PST 2020
On 2020-03-03 02:16, Thomas DeBellis wrote:
> Nope, I forgot. So now I just did and got the following interesting
> selections:
>
> NCP>set exeCUTOR nODE VENTI2:: ? one of the following:
> ACCOUNT PASSWORD USER
> or confirm with carriage return
>
> So I guess that's how Tops-20 parses for it. So I suppose--assuming
> NMLT20 is actually going to swallow this particular parse tree--that
> Tops-20 is like RSX and authenticates on a node and not a circuit basis.
RSX don't even authenticate on a node basis. As I said, it's not "SET
EXECUTOR NODE ..." it is "SET EXECUTOR TRANSMIT PASSWORD ...".
In RSX, it's global. Enable it, and you have it everywhere, and the same
password everywhere. No way of any finer granularity. Rather unsatisfying...
> When I talk about what was written in BLISS and what wasn't, I am
> talking about a /seriously/ long time ago. The first thing that DEC did
> when I started in 1979 was stick me in a BLISS class and the mantra was
> BLISS everywhere. That was over 40 years ago... I can't even remember
> what I had for breakfast yesterday.
>
> Some of the Tops-20 monitor code for DECnet started out and was debugged
> under Tops-10. However, this is Macro-10.
Oh, I know DEC did move a lot to BLISS. But DECnet-11M wasn't among
them, ever. There are only a couple of things in RSX written in BLISS.
On the DECnet side, that is PHONE, and then some Professional specific
modules that were tailored for P/OS.
In RSX itself, some file system related stuff is in BLISS, but not much
else.
Johnny
>
> On 3/2/20 8:07 PM, Johnny Billquist wrote:
>> Did you see any SET EXEC TRANSMIT PASSWORD maybe?
>>
>> Anyway, the NCP parsing in RSX is all written in MACRO-11, so it was
>> never shared with anything written in BLISS.
>>
>> Johnny
>>
>> On 2020-03-03 00:55, Thomas DeBellis wrote:
>>> I appear to have neither CIRCUIT VERIFICATION nor NODE TRANSMIT
>>> PASSWORD, viz:
>>>
>>> NCP>set cirCUIT ni-0 ? ALL
>>> or one of the following:
>>> ACTIVE BABBLE BLOCKING CHANNEL COST
>>> COUNTER DEAD
>>> DTE DYING HELLO INACTIVE LINE
>>> LISTEN MAXIMUM
>>> NUMBER OWNER POLLING RECALL ROUTER
>>> SERVICE STATE
>>> TRANSMIT TRIBUTARY TYPE USAGE
>>>
>>> NCP>set noDE venti2:: ? ALL
>>> or one of the following:
>>> ADDRESS CIRCUIT
>>> or one of the following:
>>> AREA BROADCAST BUFFER CONSOLE COUNTER
>>> CPU DELAY DIAGNOSTIC DUMP HARDWARE
>>> HOST IDENTIFICATION INACTIVITY INCOMING LOAD
>>> MAXIMUM OUTGOING RETRANSMIT ROUTING SECONDARY
>>> SEGMENT SERVICE SOFTWARE STATE SUBADDRESSES
>>> TERTIARY TYPE
>>>
>>> I may be mis-remembering how our DN200 was configured. I believe the
>>> Top-20 NCP parser may have shared keyword tables with other DECnet
>>> implementations via BLISS at one point. Anyway, I recall at least
>>> some of it was BLISS. I haven't look in that particular box lately,
>>> but the parse tables appear to assembler now, with heavy uses of
>>> GLXMAC macros.
>>>
>>> The Tops-20 operator interface has two 'sub-modes', as it were: NCP
>>> and LCP. NCP parses DECnet related keywords. LCP is used for LAT
>>> configuration. The operator subsystem is kind of neat; OPR parsers
>>> send packets to Orion, a communications server and router. It notes
>>> an NCP subset and routes that to NMLT20 which contains just what you
>>> think it would.
>>>
>>> Early versions of NMLT20 (about 1980) appeared insufficiently
>>> productized. It could hang in a loop or (more frequently) crash for
>>> no readily apparent reason. We submitted a rather large number of
>>> SPR's... However, it's quite stable now; I don't believe I've had a
>>> single crash. I have yet to come to a fully informed conclusion
>>> about the lexical interface; I sometimes get the impression that it
>>> parses for more than it can actually do.
>>>
>>> Elsewhere in Tops-20, DECnet implementation is a mixed bag; most of
>>> the monitor code appears finished; I go months without reboots and
>>> that is with active development. The user mode code is another
>>> matter entirely. I had my hands full fixing a number of issues with
>>> DAP and FAL. It was /invaluable/ having heterogeneous HECnet nodes to
>>> test against, RSX 11M+ and VMS. SETNOD needs some finishing and
>>> perhaps some additional functionality. I have yet to look at FTS; I
>>> don't see how it can get or generate any traffic at all. The monitor
>>> interface (NFT:) does not appear to be operational. Elsewhere
>>> (perhaps Galaxy) appears to have no submission interface. Johnny and
>>> I have some minor tweaks to flush out with MAIL11 (in addition to the
>>> changes that I've already put in).
>>>
>>>
>>> On 3/2/20 3:25 PM, Robert Armstrong wrote:
>>>>
>>>> >I don't see where I would set an id and password in 7-1-CONFIG or
>>>> in NCP.
>>>>
>>>> Don’t know about TOPS-20, but in NCP/NICE/NML it’s
>>>>
>>>> SET CIRCUIT … VERIFICATION ENABLED
>>>>
>>>> and
>>>>
>>>> SET NODE … TRANSMIT PASSWORD …
>>>>
>>>> The password the remote node sends has to match the one that’s
>>>> associated with that node in the local DECnet database.
>>>>
>>>> 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
More information about the Hecnet-list
mailing list