[HECnet] My RSTS/E system...

[Paul Koning]

> On Aug 13, 2018, at 5:56 AM, Johnny Billquist <bqt at softjar.se> wrote:
> 
> Interesting stuff actually.
> 
> Let me comment each one with what I understand...
> 
> On 2018-08-13 07:45, Mark Abene wrote:
>> This is what I saw on my end:
>> Event type 34.0, Object spawned
>> Occurred 29-Jul-31 13:19:43.4 on node 61.151 (MARDUK)
>> Source node = 1.13 (MIM)
>> Source process = 0 0 0 BILLQUIST
>> Destination process = 19
>> User = 61,1
>> Password = ...
> 
> This would be NICE, which is object 19. I do not get any response when I try to talk NICE to MARDUK. I'm also not providing any authentication information, so it would seem 61,1 is the default account, or something, that DECnet on your machine is using.
> 
> I'm kindof wondering why I'm not getting any response to NICE requests. But, as noted before, I do get an network resources error. If I had an account, it could be interesting to try authenticating myself and see if that helped. Especially if 61,1 don't even exist as an account on MARDUK.

Clearly an attempt to connect using a nonexistent PPN should fail, and I would expect it to fail prior to spawning the object ("fork" in Unix terminology).  However, see below.

>> ...
> 
>> Event type 34.0, Object spawned
>> Occurred 29-Jul-31 17:10:43.8 on node 61.151 (MARDUK)
>> Source node = 1.13 (MIM)
>> Source process = 0 0 0 BILLQUIST
>> Destination process = 23
>> User = 1,2
>> Password = ...
> 
> Object 23 is the predecessor of CTERM. I'm not entirely sure of the name of that protocol. Anyway, I never logged in. Using the normal RSX program for connecting gives me a protocol error. Using the RSTS/E specific program did allow me to connect, but did crash RSX afterwards. But I never logged in. But I guess the user here is just under which the server itself would be running, and not anything I provided.

Yes.

Object configuration is OS-specific.  In RSTS, it is accessible via NICE if you use the correct OS-specific protocol code and field numbers.  

Authorization in RSTS offers a choice of 3 options.  One is to pass the access control parameters to the program for it to handle.  That's the backward compatibility option; it isn't intended to be used by any DEC-supplied objects, or any newly written user objects.

The second choice is not to look for access control fields and log the object in to a fixed PPN.  This is used for objects that aren't doing file access or the like on behalf of a given user.  It applies to the network terminal protocol listener, for example, and to mail.

The third choice is for RSTS to check access control on behalf of the object, then if successful log it into the supplied PPN.  That applies to FAL, obviously, and also to other objects like NICE that use PPN/password based authorization.

In the example for NICE that Mark quoted, I wonder if NICE has been set to the old-style authorization.  The way to answer that question is "ncp show known object characteristics".

	paul