As I recall, on VMS, SYSPRV privilege was effectively granted to any
process whose UIC was in a “system” group. By default this was all UICs from [1,*] to [10,*] (octal), but I recall docs saying the upper limit was configurable.

I also recall that, when you woke up the login prompt, the LOGINOUT
process was created running under UIC [10,40]. I wonder if this was chosen
to ensure that sysadmins would never lower the upper bound below 10 octal,
they could only raise it? Did the UIC [10,40] have any other significance? Perhaps something from RSX-11 days?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro schrieb am 07.06.2024 um 04:32:

As I recall, on VMS, SYSPRV privilege was effectively granted to any
process whose UIC was in a “system” group. By default this was all UICs from [1,*] to [10,*] (octal), but I recall docs saying the upper limit was configurable.

SYSGEN> help sys_para maxsysgroup

Sys_Parameters

MAXSYSGROUP

MAXSYSGROUP sets the highest value that a group number can have
and still be classified as a system UIC group number. Note that
the specification is not in octal unless preceded by the %O radix
indicator. This parameter is normally left at 8 (10 octal).

MAXSYSGROUP is a DYNAMIC parameter.

I also recall that, when you woke up the login prompt, the LOGINOUT
process was created running under UIC [10,40]. I wonder if this was chosen
to ensure that sysadmins would never lower the upper bound below 10 octal, they could only raise it? Did the UIC [10,40] have any other significance? Perhaps something from RSX-11 days?

Here, LOGINOUT is running under [1,4] (usually assigned to the SYSTEM
account).

Hans.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 7 Jun 2024 11:20:34 +0200, Hans Bachner wrote:

SYSGEN> help sys_para maxsysgroup

Sys_Parameters

MAXSYSGROUP

MAXSYSGROUP sets the highest value that a group number can have
and still be classified as a system UIC group number.

Did anybody ever assign UICs to users in the [2,*] ... [10,*] groups?

It seems to me that having lots of users with system-level privileges was
not a good idea back then, and is even less desirable nowadays.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 7 Jun 2024 11:20:34 +0200, Hans Bachner wrote:

Here, LOGINOUT is running under [1,4] (usually assigned to the SYSTEM account).

Interesting. I remember seeing [10,40] back in VAX/VMS days. Must have
changed at some point.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/7/2024 7:04 AM, Lawrence D'Oliveiro wrote:

On Fri, 7 Jun 2024 11:20:34 +0200, Hans Bachner wrote:

SYSGEN> help sys_para maxsysgroup

Sys_Parameters

MAXSYSGROUP

MAXSYSGROUP sets the highest value that a group number can have
and still be classified as a system UIC group number.

Did anybody ever assign UICs to users in the [2,*] ... [10,*] groups?

Hopefully not.

It seems to me that having lots of users with system-level privileges was
not a good idea back then, and is even less desirable nowadays.

As long as I can remember it has been considered best practice
to use personal accounts above that with SETPRV for priviliged
users.

I usually use groups 100, 101, ... and 200, 201, ..., but
probably no particular reason.

DECnet like 376 and TCP/IP like 3655.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 7 Jun 2024 08:04:49 -0400, Arne Vajhøj wrote:

DECnet like 376 and TCP/IP like 3655.

Just realized that the separation between usernames and UICs is actually another misfeature of VMS.

On *nix systems, a username is always understood to map to a particular
UID. Which one is not important, just so long as it isn’t zero. This
allows various subsystems to run under their own usernames with privilege isolation, without having to worry about UID clashes. For example, the
OpenLDAP server runs under the “openldap” user, and it doesn’t matter that
that might map to a particular UID on one system, and a different one on another system.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/7/2024 7:50 PM, Lawrence D'Oliveiro wrote:

On Fri, 7 Jun 2024 08:04:49 -0400, Arne Vajhøj wrote:

DECnet like 376 and TCP/IP like 3655.

Just realized that the separation between usernames and UICs is actually another misfeature of VMS.

On *nix systems, a username is always understood to map to a particular
UID. Which one is not important, just so long as it isn’t zero. This
allows various subsystems to run under their own usernames with privilege isolation, without having to worry about UID clashes.

VMS allows multiple usernames with same UIC, but it practically
never happens.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 7 Jun 2024 20:11:13 -0400, Arne Vajhøj wrote:

VMS allows multiple usernames with same UIC, but it practically
never happens.

The point being that privilege separation is done based on UIC, not
username. For example, on *nix, a daemon might start out as root and then
call setuid(2) and friends to isolate the current process as a
nonprivileged user. The UID to use can be easily obtained by looking up a symbolic username in the /etc/passwd file. How would you do this on VMS?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/7/2024 8:26 PM, Lawrence D'Oliveiro wrote:

On Fri, 7 Jun 2024 20:11:13 -0400, Arne Vajhøj wrote:

VMS allows multiple usernames with same UIC, but it practically
never happens.

The point being that privilege separation is done based on UIC, not
username. For example, on *nix, a daemon might start out as root and then call setuid(2) and friends to isolate the current process as a
nonprivileged user. The UID to use can be easily obtained by looking up a symbolic username in the /etc/passwd file. How would you do this on VMS?

You would not do it that way on VMS.

Depending on the specific requirements you would probably
do one of:
- start daemon under a username with a minimum set of privs
(if it just need WORLD and SYSNAM, then it get just those)
- start the daemon under an unpriviliged username and install
executable with the minimum set of privs
- start the daemon under an unpriviliged username, don't
install the executable with privs but let the program
use an UWSS to do the priviliged stuff
- start daemon under a username with SETPRV privilige
and let the program use SYS$SETPRV to turn required privs
on and off dynamically
- start the daemon under an unpriviliged username and install
executable with with SETPRV privilige and let the program
use SYS$SETPRV to turn required privs on and off dynamically

So many options.

If you really want to change identity, then there are a bunch
of utilities for it SETUSER, JUMP, PERSONA etc. - I assume
that they change both username and UIC.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/6/24 10:26, Lawrence D'Oliveiro wrote:

On Fri, 7 Jun 2024 20:11:13 -0400, Arne Vajhøj wrote:

VMS allows multiple usernames with same UIC, but it practically
never happens.

The point being that privilege separation is done based on UIC, not
username.

And VMS does it by username. Some UICs on VMS are defined to be in the
system group. Some UIDs on unix are defined to be in the system group.
So what?

For example, on *nix, a daemon might start out as root and then
call setuid(2) and friends to isolate the current process as a
nonprivileged user. The UID to use can be easily obtained by looking up a symbolic username in the /etc/passwd file. How would you do this on VMS?

How do you change username (and granted identifiers and/or UIC) on VMS?

$assume_persona system service and co. You'll find they're a little
more flexible than setuid. Example here:

https://www.eight-cubed.com/examples/framework.php?file=sys_persona.c

Or did you mean "how would you look up a UIC by username? From DCL, f$identifier lexical:

$ uic = f$identifier ("SYSTEM", "NAME_TO_NUMBER")
$ write sys$output f$fao ("!%U", uic)
[1,4]
$

From an executable, $getuai system service.

On VMS, to start something with privileges and permanently drop them
after initialization and *guarantee* that the process can never get them
back (unlike both setuid and the persona system services, which can both
resume their "natural" id):

Set up a user with authorized privs of (for example) NETMBX, TMPMBX, and default privs of SYSPRV, NETMBX, TMPMBX.

When the process starts, it will have SYSPRV, but after dropping the
privilege (set proc/priv=nosysprv in DCL, $setprv system service in a
program), you cannot re-enable it. Use a captive (or restricted)
command procedure (or run a program without a command interpreter) to
ensure the process cannot retain or regain privs.

Jim

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 8 Jun 2024 11:55:46 +1000, Jim Duff wrote:

On 8/6/24 10:26, Lawrence D'Oliveiro wrote:

The point being that privilege separation is done based on UIC, not
username.

And VMS does it by username.

Last I checked, the username is only significant for accounting purposes,
not for privilege checking. And there’s also the “account name”.

$assume_persona system service and co. You'll find they're a little
more flexible than setuid. Example here:

https://www.eight-cubed.com/examples/framework.php?file=sys_persona.c

Ah, that’s new to me. Finally found some docs for it in OpenVMS 7.0.

Just a tip: instead of writing out a call twice, once to pick up the
buffer length, then doing the buffer allocation and making the call to get
the actual data, why not write the call just once and let it execute
twice? E.g.

usrpro_d.addr = NULL;
for (;;)
{
r0_status = sys$create_user_profile
(
/*usrname =*/ &system_d,
/*itmlst =*/ NULL,
/*flags =*/ 0,
/*usrpro =*/ usrpro_d.addr,
/*usrprolen =*/ &usrpro_d.length,
/*contxt =*/ 0
);
errchk_sig(r0_status);
if (usrpro_d.addr != NULL)
break;
usrpro_d.addr = malloc(usrpro_d.length);
assert(usrpro_d.addr != NULL);
} /*for*/

Less code to write, less code to maintain, less chance for bugs to get in. Overall just less work involved.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/7/24 8:55 PM, Jim Duff wrote:

On 8/6/24 10:26, Lawrence D'Oliveiro wrote:

On Fri, 7 Jun 2024 20:11:13 -0400, Arne Vajhøj wrote:

VMS allows multiple usernames with same UIC, but it practically
never happens.

The point being that privilege separation is done based on UIC, not
username.

And VMS does it by username.  Some UICs on VMS are defined to be in the system group.  Some UIDs on unix are defined to be in the system group.
So what?

For example, on *nix, a daemon might start out as root and then
call setuid(2) and friends to isolate the current process as a
nonprivileged user. The UID to use can be easily obtained by looking up a
symbolic username in the /etc/passwd file. How would you do this on VMS?

How do you change username (and granted identifiers and/or UIC) on VMS?

$assume_persona system service and co.  You'll find they're a little
more flexible than setuid.  Example here:

https://www.eight-cubed.com/examples/framework.php?file=sys_persona.c

Or did you mean "how would you look up a UIC by username?  From DCL, f$identifier lexical:

$ uic = f$identifier ("SYSTEM", "NAME_TO_NUMBER")
$ write sys$output f$fao ("!%U", uic)
[1,4]
$

From an executable, $getuai system service.

On VMS, to start something with privileges and permanently drop them
after initialization and *guarantee* that the process can never get them
back (unlike both setuid and the persona system services, which can both resume their "natural" id):

Set up a user with authorized privs of (for example) NETMBX, TMPMBX, and default privs of SYSPRV, NETMBX, TMPMBX.

When the process starts, it will have SYSPRV, but after dropping the privilege (set proc/priv=nosysprv in DCL, $setprv system service in a program), you cannot re-enable it.  Use a captive (or restricted)
command procedure (or run a program without a command interpreter) to
ensure the process cannot retain or regain privs.

Depending on what the real question was, you might also end up calling sys$create_user_profile to get the rights and privileges of the current process.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-06-08 01:08:56 +0000, Arne Vajhøj said:

You would not do it that way on VMS.

Depending on the specific requirements you would probably
do one of:
- start daemon under a username with a minimum set of privs (if it just
need WORLD and SYSNAM, then it get just those)
- start the daemon under an unpriviliged username and install
executable with the minimum set of privs
- start the daemon under an unpriviliged username, don't install the executable with privs but let the program use an UWSS to do the
priviliged stuff
- start daemon under a username with SETPRV privilige and let the
program use SYS$SETPRV to turn required privs on and off dynamically
- start the daemon under an unpriviliged username and install
executable with with SETPRV privilige and let the programuse SYS$SETPRV
to turn required privs on and off dynamically

OpenVMS doesn't have concepts related to app (username and UIC)
isolation, so the whole area is clunky at best and many of the knobs
and settings (including usernames and UICs) are system-wide, and can be
prone to collisions. Third-party app installs can easily run afoul of
this area with the potential for conflicting system-wide constructs
including usernames; with stuff that can collide and requires manual coordination.

Newer API designs and concepts including pledge(2) and related, and
related to jails / sandboxing, are lacking on OpenVMS, which means
using privileges or probably preferably creating and configuring and
using identifiers.

The closest analog to some of the older and clunkier primitives
including setuid(2) involves is setting the privileges in the default
mask and not set in the authorized mask. (When those privileges in the
default are dropped, they cannot be recovered.) And the UNIX UID design
is closer to granting the UIC to the user, which is somewhat different
from how OpenVMS is organized. OpenVMS sprouted from RSX-11 here, with
the UICs coming first and usernames being added later. And this
heritage is why all the numeric UICs are still visible around the
system, including everybody's favorite [0,0] directory, err, [000000].
Through compatibility efforts, OpenVMS has morphed UICs into a
particular form of an identifier in most places (other than the
oldest), but that transition is only when looking at the details and is
not clearly documented.

Other options for granting access involve subsystem identifiers, which
are usually (often? always?) preferable to messing with privileges and
UICs.

And the auxiliary server (also known as inetd) is another common way to
get processes started under a particular context, as a newer version of
using DECnet task-to-task and objects as was common in yet older
environments.

So many options.

If you really want to change identity, then there are a bunch of
utilities for it SETUSER, JUMP, PERSONA etc. - I assume that they
change both username and UIC.

It's fairly rare to change the user context in recent years, as it
tends to play havoc with accountability in the logs and telemetry data.
There's also "fun" around the username and its logical names and login
context, which some APIs have handled swapping that better than have
others.

BTW(1), UICs are a design that originated in the 1970s and quite
probably earlier, and various newer systems are using GUIDs to avoid
the inevitable messes that are inherent with UICs. OpenVMS does poorly
at this whole area, particularly if recycling or reusing UICs. Stale identifiers and stale UICs can be left scattered around the system,
quite possibly waiting months or years before causing confusion or
exposures around access permission or access blockages. Wrote up a
scrubbing tool ACL_SCRUB that was able to contend with this mess, but
not sure if that tool is publicly hosted anywhere right now—I still
have a copy stashed away locally, if there's interest.

BTW(2), SYSPRV came second, and is the privilege equivalent of a system
UIC. The UIC came first.

BTW(3), users assigned system UICs were pretty common in years past,
with various folks placing system staff in [2,*], or in one of the
other system UIC groups. I used this assignment to gain control of and
manage a problematic PDP-11 RSX-11 system an aeon ago.

BTW(4), Some arcana, if you have somebody that's security curious, but
not authorized to have privileges—enabling SETPRV in the user's default
mask has no effect to system security, other than causing some few
folks that do notice some (failing) efforts to try to use that
privilege bit.

--
Pure Personal Opinion | HoffmanLabs LLC

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stephen Hoffman <seaohveh@hoffmanlabs.invalid> writes:

BTW(1), UICs are a design that originated in the 1970s and quite probably earlier

"UIC" is a renaming of the concept of project-programmer number, or PPN, introduced in DEC systems with the PDP-6, DEC's first multiuser mainframe product (April 1964 announcement, June 1964 FCS). To that time, DEC systems were oriented to the single user, with offline accounting for files (on paper tape or DECtape).

The PPN concept was kept on the successful PDP-10 follow-on product, and adopted by the creators of TSS/8 for the PDP-8i (who were developers on the second generation DECsystem-10) in 1970; its use then spread to the PDP-15 and the PDP-11 as the UIC in RSX-15 and RSX-11.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10 Jun 2024 16:26:20 -0400, Rich Alderson wrote:

"UIC" is a renaming of the concept of project-programmer number, or PPN, introduced in DEC systems with the PDP-6, DEC's first multiuser
mainframe product (April 1964 announcement, June 1964 FCS).

So “PPN” was the term used in TOPS-10 (and whatever the PDP-6 precursor OS was), and also RSTS-11/RSTS/E, as well. It was decimal in the latter; was
it decimal or octal in the PDP-6/10?

“UIC” was the term used in RSX-11, and passed on from there into VMS. That was octal in both systems.

A separation of terminology indicating some kind of cultural separation
within DEC itself?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 10 Jun 2024 15:26:11 -0400, Stephen Hoffman wrote:

including everybody's favorite [0,0] directory, err, [000000].

I can remember that “[000000...]” was a valid directory wildcard spec, but “[0,0...]” was not.

Also remember “<” ... “>” was valid for directories, and a dot instead of
semicolon for file versions, à la TOPS-10.

And the auxiliary server (also known as inetd) is another common way to
get processes started under a particular context, as a newer version of
using DECnet task-to-task and objects as was common in yet older environments.

Is it called inetd on VMS?

I can remember various “inetd” and “xinetd” servers, depending on the flavour of *nix. Nowadays systemd offers a more modular way of managing
things.

From VMS days, I vaguely remember those numbers you had to specify for
DECnet connections, e.g. “23=” for a remote terminal connection, “0=” or
“task=” for running your own arbitrary remote command, something else for FAL (remote file access) etc. Other systems soon settled on the idea of
server processes listening for connections on particular ports (e.g. file servers), but for some reason DEC never cottoned on to that concept.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On 10 Jun 2024 16:26:20 -0400, Rich Alderson wrote:

"UIC" is a renaming of the concept of project-programmer number, or PPN,
introduced in DEC systems with the PDP-6, DEC's first multiuser
mainframe product (April 1964 announcement, June 1964 FCS).

So "PPN" was the term used in TOPS-10 (and whatever the PDP-6 precursor OS was), and also RSTS-11/RSTS/E, as well. It was decimal in the latter; was
it decimal or octal in the PDP-6/10?

I've only seen the PDP-6 OS referred to as "TOPS-6" in one place, but it was a DEc publication, so...

The PPN consisted of a pair of 6 digit octal numbers. Project numbers 1-10 were reserved to system usages; system programmers usually had PPNs in the [10,oooooo] range. This of course meant that a PPN ttook up a single word.

(On TSS/8, account numbers were usually represented as a 4 digit octal number,
but this was subdivided into a 2 digit project and a 2 digit programmer number.)

If you ever encountered a CompuServe ID, you were looking at a Tops-10 PPN in a different syntax.

On the WAITS operating system created at SAIL, PPNs were used, but they differed from their PDP-6/PDP-10 monitor predecessors in that they were SIXBIT (truncated ASCII) rather than octal numbers. Thus, my login PPN on SAIL was 1,RMA (directory was [1,RMA]), but this was represented in memory as 000021,,625541.

"UIC" was the term used in RSX-11, and passed on from there into VMS. That was octal in both systems.

RSX-15 was the original; RSX-11 was a reimplementation on the 16-bit hardware. But yes, VMS got it from RSX-11M, its immediate ancestor.

A separation of terminology indicating some kind of cultural separation within DEC itself?

Since each product line was a separate culture, by design, that's hardly surprising.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Mon, 10 Jun 2024 15:26:11 -0400, Stephen Hoffman wrote:

including everybody's favorite [0,0] directory, err, [000000].

I can remember that "[000000...]" was a valid directory wildcard spec, but "[0,0...]" was not.

Also remember "<" ... ">" was valid for directories, and a dot instead of semicolon for file versions, à la TOPS-10.

TOPS-20, not Tops-10. Tops-10 filespecs were always, and only[1], of the form

DEVICE:FILNAM.TYP[P,PN{,SFD{,SFD{,SFD{,SFD{,SFD}}}}}]

where the braces are a metasyntactic indication that up to 5 levels of "subfile directory" could be specified. It wasn't *really* a hierarchical file system, but it kind of looked that way.

[1] The user could type the PPN before the file name+type, but if she asked the OS to echo it back, it would come out in the canonical form.

TOPS-20 filespecs:

DEVICE:<DIRECTORY{.*}>FILENAME.FILETYPE.VERSION

where a hierarchical directory specification could be up to 39 characters long, and a file name and file type string cold be up to 39 characters long. The version was a decimal number in the range 1--131071.

In the TENEX predecessor to TOPS-20, the separator for the version number was a semicolon rather than a period.

WAITS never implemented the SFD concept.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11 Jun 2024 21:01:50 -0400, Rich Alderson wrote:

If you ever encountered a CompuServe ID, you were looking at a Tops-10
PPN in a different syntax.

It just clicked with me that CompuServe were using a lot of TOPS-10
machines, and that was well into the 1980s.

RSX-15 was the original; RSX-11 was a reimplementation on the 16-bit hardware.

That I never knew.

A separation of terminology indicating some kind of cultural
separation within DEC itself?

Since each product line was a separate culture, by design, that's
hardly surprising.

Still, it has to be said, DEC’s product lines were never quite as
fragmented as, say, IBM’s.

Consider that IBM is credited with inventing “virtual machines”, but this wasn’t some elegant resource-management technology, it was just a big
hack, initially to offer timeshared multi-user service for an OS (CMS)
that was interactive, but only single-user.

Whereas on the PDP-11, DEC created RSTS/E, which somehow managed to
directly run a subset of binaries from RT-11 and RSX-11, in addition to
its own native ones.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11 Jun 2024 21:15:57 -0400, Rich Alderson wrote:

TOPS-20, not Tops-10.

Ah. So “< ... >” was an idea copied from BBN, not DEC home-grown?

Did TOPS-10 allow “( ... )” in place of “[ ... ]”? Because I remember RSTS/E did.

... where a hierarchical directory specification could be up to 39
characters long, and a file name and file type string cold be up to
39 characters long. The version was a decimal number in the range
1--131071.

Signed 18-bit version numbers, of course.

Interesting that VMS should have reduced the filename length to 9-dot-3 (à
la RSX?) in initial versions, then increased it again to 39-dot-39 in VMS
V4.

In the TENEX predecessor to TOPS-20, the separator for the version
number was a semicolon rather than a period.

How odd that DEC should have changed it to a dot in TOPS-20, then brought
back the other form as well for VMS ...

One little nicety about version specs was that the DELETE command insisted
on them, whereas most other commands didn’t care. This was a subtle way of making file deletion take a little bit of extra mental effort to invoke,
as befitting its potentially dangerous status. (Better than those tedious “Are you sure?” confirmation messages that are all too commonly used.)

However, some users took this to mean you actually had to put an explicit version number in, when all you had to do was have the semicolon present
(or an extra dot), and that would mean “the most recent version” as usual.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On 11 Jun 2024 21:15:57 -0400, Rich Alderson wrote:

TOPS-20, not Tops-10.

Ah. So "< ... >" was an idea copied from BBN, not DEC home-grown?

Did TOPS-10 allow "( ... )" in place of "[ ... ]"? Because I remember
RSTS/E did.

No.

... where a hierarchical directory specification could be up to 39
characters long, and a file name and file type string cold be up to
39 characters long. The version was a decimal number in the range
1--131071.

Signed 18-bit version numbers, of course.

Yes. Negative values had special meanings, similar to but different in detail from VMS.

Interesting that VMS should have reduced the filename length to 9-dot-3 (a
la RSX?) in initial versions, then increased it again to 39-dot-39 in VMS
V4.

When VMS 4.0 was demoed for the director of the UChicago Comp Center in advance of the release, she called it "TOPS-32".

In the TENEX predecessor to TOPS-20, the separator for the version
number was a semicolon rather than a period.

How odd that DEC should have changed it to a dot in TOPS-20, then brought back the other form as well for VMS ...

The generation number in RSX-20F (based on RSX-11D with addons from RSX-11M) also used a semicolon. I didn't use -11M or -11D (aka IAS) until the 21st Century (thank you, Bob Supnik!), so I don't remember whether they had file generations but I expect that they did. -20F was the version run in the PDP-11/40 front end on a KL-10 based -10/-20 system; the disk driver was modified to use 18-bit formatted RP06 instead of 16-bit, and the FILES-11
area was allocated when the disk was formatted. (Initial boot was from TU56 DECtapes or RX01 floppies.)

One little nicety about version specs was that the DELETE command insisted
on them, whereas most other commands didn't care. This was a subtle way of making file deletion take a little bit of extra mental effort to invoke,
as befitting its potentially dangerous status. (Better than those tedious "Are you sure?" confirmation messages that are all too commonly used.)

In TOPS-20, you have the choice of no version (all generations), explicit version, version = 0 for latest version, version = -1 for next higher new version, version = -2 for oldest version, version = "*" again for all versions.

However, some users took this to mean you actually had to put an explicit version number in, when all you had to do was have the semicolon present
(or an extra dot), and that would mean "the most recent version" as usual.

Not in TOPS-20, where that would be equivalent to "all versions".

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)