> On Dec 24, 2023, at 9:23 AM, Bill Gunshannon via cctalk
> <cctalk@classiccmp.org> wrote:
>
>
>
> I am back to playing with RSTS/E 10.1 again and have a couple questions
> if there is still anyone around with experience.
>
> First: Is there a way to change the allowed length for passwords?
The minimum length defaults to 6; the max is 6 for passwords that can be looked
up (not hashed) and 14 otherwise. The max is fixed. You can change the min by
patching module OVR, address ..MPWD to the value you want.
> Second: Is there a way to make login take the assigned name rather than
> the x,x format for logins? I seem to remember using a system once that
> did but I have no idea if it was legit or a local hack. Although I have
> no problem using local hacks. :-)
No. There was a "named accounts" A/D project in the V8.0 era, and fragments of
that may have made it out the door in that version. It worked reasonably well
in the development systems at the time, as I recall. But it was never
finished. If any of it remained in the code, that was all removed by V9.
Interestingly enough, it certainly could have been done in V9 more easily than
in V8, given the new file structure, but none of that was ever undertaken that
I know of.
FYA, another incomplete piece of work (this one in V9.0) was "installed files".
Those were files left permanently open, so you could access them without a
directory search. That wasn't all that interesting, but a variant of that
operation would install the file with an associated privilege mask. The idea
was for "privileged programs" to be selectively privileged, just as account are
in V9 and later. I got that working but we never did the followup work needed
to sort out exactly what privs each privileged program actually needs, so the
old approach (all or nothing) continued to be in use.
> Need to get a system going and maybe even join HECNET.
> I really wish there was TCP/IP for RSTS.
I found one for V8.0, described as by "Stacken, Royal Institute Of Technology,
Stockholm, Sweden". I haven't tried to use it. A logical approach would be
to update it for V10.1 and hook it to the standard Ethernet drivers in that
release. The original comes with a DELUA driver, and a document describing it
-- in Swedish. It's clearly not the same API as the Ethernet drivers in RSTS,
which have an extended set of "I/O service" function codes for use by kernel
components like DECnet or LAT. So, minimally, porting that code would involve
updating it to that API.
I forgot where I found this code. Johnny, do you know about it?
paul
