In C, every program is provided the number of arguments from the command line (int argc) and an array of those arguments (char *const argv[]).

I'm using Lars' libc and a derivative of gcc's C compiler to build compiler test programs, and I want to be able to handle command-line arguments. I haven't located any description (so far) regarding how a TOP20 executable might do this. Does anyone have any pointers (or might disabuse me of the idea)?

-+- Sid

Sid Maxwell <srmaxwell3@gmail.com> writes:
>In C, every program is provided the number of arguments from the command li=
>ne (int argc) and an array of those arguments (char *const argv[]).
>
>I'm using Lars' libc and a derivative of gcc's C compiler to build compiler=
> test programs, and I want to be able to handle command-line arguments. I =
>haven't located any description (so far) regarding how a TOP20 executable m=
>ight do this. Does anyone have any pointers (or might disabuse me of the i=
>dea)?

VMS had lib$get_foreign, perhaps TOPS has something similar?

;++
; Get the foreign command line.
;--
pushaq foreign_block
calls #1,lib$get_foreign
;++
; Set up and call TPARSE to parse the input string.
;--
movzwl foreign_block,parse_block+TPA$L_STRINGCNT
movl foreign_block+4,parse_block+TPA$L_STRINGPTR
pushal pmon$key
pushal pmon$state
pushal parse_block
calls #3,lib$tparse
blbs r0,3042$
3022$:
$dclast_s astadr=pmon$ctrap,astprm=#3
3042$:

TOPS-20 has RSCAN (JSYS 500), to store and retrieve command lines.
(I think it's a DEC added JSYS, so I don't know what TENEX did...)

This differs from the TOPS-10 RESCAN call, which, ISTR put the command line in the TTY input buffer.

Aren't there any existing TOPS-10 C libraries (UTAH, KCC) available to look at?

On Friday, August 11, 2023 at 12:25:50 PM UTC-7, Phil Budne wrote:
> TOPS-20 has RSCAN (JSYS 500), to store and retrieve command lines.
> (I think it's a DEC added JSYS, so I don't know what TENEX did...)

I was looking at:

https://www.livingcomputers.org/UI/UserDocs/TOPS-20-v7-1/4_TOPS-20_Monitor_Calls_Reference_Manual.txt

and especially the COMND monitor call.

It isn't so obvious that is what is wanted. It seems that things don't work quite the same way as Unix.

Much seems to be related to editing command lines, like some Unix shells allow you to do.

gah4 wrote:
> Phil Budne wrote:
>> TOPS-20 has RSCAN (JSYS 500), to store and retrieve command lines.
>> (I think it's a DEC added JSYS, so I don't know what TENEX did...)
>
> and especially the COMND monitor call.

I don't know much about TOPS-20 programming, but if I understand
correctly, COMND is a way for applications to use the nice TOPS-20
command line interface with on-line help, noise words, completion, etc.
So it's much more than just getting the command line arguments in the
Unix style. But then, if you're writing a TOPS-20 application, that's
probably the way to go.

If you really want the Unix style command line, it seems to me Phil was
right to point to RSCAN. E.g. taking a hint from the KCC runtime
library, we can see RSCAN is invovled.

https://github.com/PDP-10/sri-nic/blob/master/files/fs/kcc-6/lib/usys/urt.c#L924

On Saturday, August 12, 2023 at 12:11:40 AM UTC-7, Lars Brinkhoff wrote:

(snip)

> If you really want the Unix style command line, it seems to me Phil was
> right to point to RSCAN. E.g. taking a hint from the KCC runtime
> library, we can see RSCAN is invovled.

I guess so. But again, it is the difference between Unix and others.
The description of RSCAN says:

"This facility
allows a program to receive information that will be used as primary
input for another program before this other program reads input from
the terminal."

So, what you are saying, is that it also works if it is the same program.

For Unix, running another program, as its own process and PID is usual.
Not so usual for TOPS-20, so they have strange ways to do it.

It sounds to me like it is supposed to be used to pass data to a program
that is being run by another program.

On 2023-08-12 09:11, Lars Brinkhoff wrote:
> gah4 wrote:
>> Phil Budne wrote:
>>> TOPS-20 has RSCAN (JSYS 500), to store and retrieve command lines.
>>> (I think it's a DEC added JSYS, so I don't know what TENEX did...)
>>
>> and especially the COMND monitor call.
>
> I don't know much about TOPS-20 programming, but if I understand
> correctly, COMND is a way for applications to use the nice TOPS-20
> command line interface with on-line help, noise words, completion, etc.
> So it's much more than just getting the command line arguments in the
> Unix style. But then, if you're writing a TOPS-20 application, that's
> probably the way to go.

Uh? It's a completely different thing to print out a prompt and read a
line from the user inside the program, compared to find out what command
was given to the EXEC to invoke the program.

Obviously, there must be a way to find out what arguments and so on was
used to invoke the program under TOPS-20, just as under Unix.

And it's not really much different than Unix.

Think of COMND as something similar to the readline library in Unix.
Obviously very nice and useful. (Although COMND is much fancier...)

But it have nothing to do with how the program was invoked, and can't be
used to find out what arguments was passed at program invocation.

RSCAN might be the thing. I don't know. Some T20 hacker should be able
to answer this easily, I would think.

Johnny

Sid Maxwell <srmaxwell3@gmail.com> writes:

> In C, every program is provided the number of arguments from the command line
> (int argc) and an array of those arguments (char *const argv[]).

> I'm using Lars' libc and a derivative of gcc's C compiler to build compiler
> test programs, and I want to be able to handle command-line arguments. I
> haven't located any description (so far) regarding how a TOP20 executable
> might do this. Does anyone have any pointers (or might disabuse me of the
> idea)?

Hi, Sid,

You have been pointed at RSCAN% and COMND%, neither of which is the answer to
your question.

Command line arguments are passed in the process storage block, a data
structure associated with each process in the monitor. The PSB is accessed by
a user program via the PRARG% monitor call, which can both read the command
line as parsed by the EXEC (or other programs) and change values in the PSB
programmatically.

For hysterical raisins, compilers and the Macro-10 assembler use Tops-10
command syntax internally in the PSB in the DEC supplied versions of these
tools (which were intended to be common across operating systems). I don't
know what the C compiler does, because I have never been interested in
programming in that language on these systems.

I suggest looking at the C runtime routines to see how, or if, it utiltizes
PRARG%.

--
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

On Saturday, August 12, 2023 at 6:23:49 PM UTC-4, Rich Alderson wrote:
> You have been pointed at RSCAN% and COMND%, neither of which is the answer to
> your question.

Right. While Tenex/Tops-20 were in the same vintage as most Unix, they had a different philosophy.

If one backs up a bit, in Tops-20, the user types commands into a user program named EXEC.
There is nothing higher up the process/food chain. The operating system creates a job,
and starts running the EXEC program which accepts input. EXEC is just a usermode program that
does input the usual way, no special privs, abilities, etc.
Early versions of EXEC did command parsing
using assorted JSYS, and later version (version 3 under DEC) added the COMND% jsys which handled
a lot of the setup and administrivia, but just used other JSYS internally.

So stylistically, a Tops-20 program would start up, and ask the user to type in commands. The program asks by
calling the COMND% jsys, which types the prompt, and accepts input. It will do filename completion, type "guide words" for the user,
handle ? to list options, etc. So there was no concept of "arguments from the shell to the program"
as there was (1) no shell and (2) the program itself asked for the argument

(you might say that EXEC was like a normal *nix shell, say bash, but that is not really accurate.
for most 20 sites, EXEC was always the top level executing user-space program. We modified our version
of the TOPS-20 monitor to allow the user to have alternative top level command processors.
In early days of Tenex, there were various command shells as experiments, and one idea was
that Tenex could have the same user interface as other operating systems. Some old-time Tenex folks
probably remember the names of some of these command processor programs)

The usual *nix stdin/stdout and pipes was not directly mappable to Tops-20.
There was device assignment, but it was not the same thing at all. Pipes appeared in
some of the hacks that CMU did, especially related to their PCL (programmable command language)
research. But pipes were not part of the mainline Tops-20 world by the time that I left Tops-20 after the
death of Jupiter

On Saturday, August 12, 2023 at 7:56:23 PM UTC-7, fishtoprecords wrote:

(snip)

> The usual *nix stdin/stdout and pipes was not directly mappable to Tops-20.
> There was device assignment, but it was not the same thing at all. Pipes appeared in
> some of the hacks that CMU did, especially related to their PCL (programmable command language)
> research. But pipes were not part of the mainline Tops-20 world by the time that I left Tops-20 after the
> death of Jupiter

Not pipes, but TOPS-10 has MIC, so one program can write input to another program.

But okay, for much of DEC operating systems, the system runs a different program,
and with different arguments, or input data, then one types.

(Note first, though, that Unix shells modify the command line before it is seen by programs,
expanding shell variables, environment variables and wildcard characters.)

For some DEC systems, I believe including TOPS-10, if you type COPY A.TXT B..TXT

it actually runs:

R PIP
*B.TXT=A.TXT

so it is not command line input, but actual program input.

Past that, I haven't thought for a long time how TOPS-10 processes a
command line, and runs programs indicated.

While obviously Unix and T20 are different operating systems, and of
course things don't work the same way, I would say there are certainly
still a bunch of parallels you can draw...

On 2023-08-13 04:56, fishtoprecords wrote:
> On Saturday, August 12, 2023 at 6:23:49 PM UTC-4, Rich Alderson wrote:
>> You have been pointed at RSCAN% and COMND%, neither of which is the answer to
>> your question.
>
> Right. While Tenex/Tops-20 were in the same vintage as most Unix, they had a different philosophy.
>
> If one backs up a bit, in Tops-20, the user types commands into a user program named EXEC.
> There is nothing higher up the process/food chain. The operating system creates a job,
> and starts running the EXEC program which accepts input. EXEC is just a usermode program that
> does input the usual way, no special privs, abilities, etc.

This isn't actually that different from a shell. It's also a normal user
program, and from which all other programs you request are invoked. Just
like in Unix. No special privs, abilities or anything.

The difference might just be that in Unix, your shell itself is started
by the login process, which in turn is usually started by getty, which
in turn is started by init, which is the mother of all processes.

So you have a bit more of a hierarchy there. I'm not sure exactly how to
map all those parts into TOPS-20 (it's been a while since I even
properly played with TOPS-20). EXEC is running on the terminal even
before you log in, but there is a login program as well, I think. But
how EXEC is started for each terminal I don't know.

> So stylistically, a Tops-20 program would start up, and ask the user to type in commands. The program asks by
> calling the COMND% jsys, which types the prompt, and accepts input. It will do filename completion, type "guide words" for the user,
> handle ? to list options, etc. So there was no concept of "arguments from the shell to the program"
> as there was (1) no shell and (2) the program itself asked for the argument

Well. Many programs can certainly run using just what you give on the
command line without any prompting. The EXEC knows about commands and
what arguments they take, and do the processing before the program is
even started. But sure, EXEC only knows about commands, not random
binaries. You can teach it more commands, if I remember right. But if
it's a program/command the EXEC don't know about, then you won't get any
fancy processing in the EXEC for it, sure.

> (you might say that EXEC was like a normal *nix shell, say bash, but that is not really accurate.
> for most 20 sites, EXEC was always the top level executing user-space program. We modified our version
> of the TOPS-20 monitor to allow the user to have alternative top level command processors.
> In early days of Tenex, there were various command shells as experiments, and one idea was
> that Tenex could have the same user interface as other operating systems. Some old-time Tenex folks
> probably remember the names of some of these command processor programs)

I don't know why you think that is so different than the Unix shell(s).
Yes, there are differences in the details, but I would say there are way
more similarities than differences.

> The usual *nix stdin/stdout and pipes was not directly mappable to Tops-20.

That on the other hand is very true.

Johnny

Thanks, all! The history and technical pointers are all very appreciated, and I think I've got enough to make progress.

I find it fascinating that legacy systems such as these are still relevant in various ways, and that one can still find folks who can perpetuate knowledge that make new things possible and worthwhile.

-+- Sid

Johnny Billquist <bqt@softjar.se> writes:
>While obviously Unix and T20 are different operating systems, and of
>course things don't work the same way, I would say there are certainly
>still a bunch of parallels you can draw...
>
>On 2023-08-13 04:56, fishtoprecords wrote:
>> On Saturday, August 12, 2023 at 6:23:49 PM UTC-4, Rich Alderson wrote:
>>> You have been pointed at RSCAN% and COMND%, neither of which is the answer to
>>> your question.
>>
>> Right. While Tenex/Tops-20 were in the same vintage as most Unix, they had a different philosophy.
>>
>> If one backs up a bit, in Tops-20, the user types commands into a user program named EXEC.
>> There is nothing higher up the process/food chain. The operating system creates a job,
>> and starts running the EXEC program which accepts input. EXEC is just a usermode program that
>> does input the usual way, no special privs, abilities, etc.
>
>This isn't actually that different from a shell. It's also a normal user
>program, and from which all other programs you request are invoked. Just
>like in Unix. No special privs, abilities or anything.

True. Unlike VMS, where DCL ran in the supervisor ring...

On 2023-08-14 17:55, Scott Lurndal wrote:
> Johnny Billquist <bqt@softjar.se> writes:
>> While obviously Unix and T20 are different operating systems, and of
>> course things don't work the same way, I would say there are certainly
>> still a bunch of parallels you can draw...
>>
>> On 2023-08-13 04:56, fishtoprecords wrote:
>>> On Saturday, August 12, 2023 at 6:23:49 PM UTC-4, Rich Alderson wrote:
>>>> You have been pointed at RSCAN% and COMND%, neither of which is the answer to
>>>> your question.
>>>
>>> Right. While Tenex/Tops-20 were in the same vintage as most Unix, they had a different philosophy.
>>>
>>> If one backs up a bit, in Tops-20, the user types commands into a user program named EXEC.
>>> There is nothing higher up the process/food chain. The operating system creates a job,
>>> and starts running the EXEC program which accepts input. EXEC is just a usermode program that
>>> does input the usual way, no special privs, abilities, etc.
>>
>> This isn't actually that different from a shell. It's also a normal user
>> program, and from which all other programs you request are invoked. Just
>> like in Unix. No special privs, abilities or anything.
>
> True. Unlike VMS, where DCL ran in the supervisor ring...

Yes. And RSX is in a way even weirder, because the CLI there is a
process that is only started once you have typed your command. The
readong and handling of the input up until you hit enter is all
happening in the terminal device driver.
But the CLI then needs to be installed and the system informed that it
is a CLI, and there are special system calls avaulable that is only for
CLIs.

And CLIs can pass the command on to other CLIs if they want to, so you
can actually have layers of CLIs, which catch different commands...

Johnny

On Monday, August 14, 2023 at 3:56:22 PM UTC-7, Johnny Billquist wrote:

(snip)

> Yes. And RSX is in a way even weirder, because the CLI there is a
> process that is only started once you have typed your command. The
> readong and handling of the input up until you hit enter is all
> happening in the terminal device driver.
> But the CLI then needs to be installed and the system informed that it
> is a CLI, and there are special system calls avaulable that is only for
> CLIs.

The system where you run programs by typing the name of the program I first
knew from Unix. For TOPS-10, and I believe TOPS-20, you type

R programname

or

RUN programname

it seems so obvious now, but wasn't so many years ago.

Other systems, you load the program into memory, and then RUN it.

gah4 <gah4@u.washington.edu> writes:
>On Monday, August 14, 2023 at 3:56:22=E2=80=AFPM UTC-7, Johnny Billquist wr=
>ote:
>
>(snip)
>
>> Yes. And RSX is in a way even weirder, because the CLI there is a=20
>> process that is only started once you have typed your command. The=20
>> readong and handling of the input up until you hit enter is all=20
>> happening in the terminal device driver.=20
>> But the CLI then needs to be installed and the system informed that it=20
>> is a CLI, and there are special system calls avaulable that is only for=
>=20
>> CLIs.=20
>
>The system where you run programs by typing the name of the program I first
>knew from Unix. For TOPS-10, and I believe TOPS-20, you type
>
>R programname

tss8 was the same way, e.g. "R PIP", or "R CAT" or "R SYSTAT".

On the Burroughs mainframes, the command interpreter was built
into the MCP (Operating System). It was invoked by input from
the console terminal(s), card reader, or programmatic OS calls.

gah4 <gah4@u.washington.edu> writes:

> On Monday, August 14, 2023 at 3:56:22=E2=80=AFPM UTC-7, Johnny Billquist wrote:

> (snip)

>> Yes. And RSX is in a way even weirder, because the CLI there is a
>> process that is only started once you have typed your command. The
>> readong and handling of the input up until you hit enter is all
>> happening in the terminal device driver.
>> But the CLI then needs to be installed and the system informed that it
>> is a CLI, and there are special system calls avaulable that is only for
>> CLIs.

> The system where you run programs by typing the name of the program I first
> knew from Unix. For TOPS-10, and I believe TOPS-20, you type

> R programname

> or

> RUN programname

> it seems so obvious now, but wasn't so many years ago.

> Other systems, you load the program into memory, and then RUN it.

By the time I first encountered TOPS-20 (version 3), programs could be invoked
at the EXEC prompt simply by typing the name of the executable file. I suspect
the same was true all the way back to TENEX, but I never worked with the older
OS.

The use of R and RUN was a UI holdover from the other operating system.

For those unfamiliar with these OSes:
1. RUN executes a program binary located in the current directory.
2. R executes a program located somewhere in the system search path (which the
user can extend as needed).

--
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

scott@slp53.sl.home (Scott Lurndal) writes:

> gah4 <gah4@u.washington.edu> writes:
>> On Monday, August 14, 2023 at 3:56:22=E2=80=AFPM UTC-7, Johnny Billquist wrote:

>> (snip)

>>> Yes. And RSX is in a way even weirder, because the CLI there is a
>>> process that is only started once you have typed your command. The
>>> readong and handling of the input up until you hit enter is all
>>> happening in the terminal device driver.
>>> But the CLI then needs to be installed and the system informed that it
>>> is a CLI, and there are special system calls avaulable that is only for
>>> CLIs.

>> The system where you run programs by typing the name of the program I first
>> knew from Unix. For TOPS-10, and I believe TOPS-20, you type

>> R programname

> tss8 was the same way, e.g. "R PIP", or "R CAT" or "R SYSTAT".

TSS/8 was written by two guys who worked on the second generation PDP-10 (the
KI-10 processor), who wanted to show that a timesharing OS was possible on a
small machine. They intentionally made it look like the PDP-10 monitor.

> On the Burroughs mainframes, the command interpreter was built
> into the MCP (Operating System). It was invoked by input from
> the console terminal(s), card reader, or programmatic OS calls.

The smae thing is true in Tops-10: The command interpreter is part of the
monitor's address space. There is a procedure for adding commands to the
interpreter during system generation, for local enhancements.

--
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

Johnny Billquist <bqt@softjar.se> writes:

[ snip ]

> The difference might just be that in Unix, your shell itself is started
> by the login process, which in turn is usually started by getty, which
> in turn is started by init, which is the mother of all processes.

> So you have a bit more of a hierarchy there. I'm not sure exactly how to
> map all those parts into TOPS-20 (it's been a while since I even
> properly played with TOPS-20). EXEC is running on the terminal even
> before you log in, but there is a login program as well, I think. But
> how EXEC is started for each terminal I don't know.

Tops-10 uses a LOGIN program, invoked by the command interpreter.

TOPS-20 has a LOGIN% system call, executed by the EXEC shell in response to the
LOGIN command. The EXEC will refuse to execute the call if the job is already
logged in.

--
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

On Tuesday, August 15, 2023 at 1:51:06 PM UTC-7, Rich Alderson wrote:

(snip)

> Tops-10 uses a LOGIN program, invoked by the command interpreter.

And some other commands can also run when not logged in.

One of those is QUEUE, useful to see where you are in the print queue
or batch queue.

Story I remember from the TOPS-10 days, is that QUEUE has the ability to run
another command when it is done. It seems a feature designed to allow a program
to run QUEUE, and then restart (continue) itself.

Someone found out that you could run QUEUE when not logged in, and also use
the ability to run another program. (Which runs on a system account.)

The sent in the bug report to DEC.
There is a box on the bug report, to publish the report.
Some checked the box.
And DEC published the bug report before reading it.

I remember from VMS days, using logical names to run programs
by name, without a RUN command.

On 2023-08-16 03:29, gah4 wrote:
> On Tuesday, August 15, 2023 at 1:51:06 PM UTC-7, Rich Alderson wrote:
>
> (snip)
>
>> Tops-10 uses a LOGIN program, invoked by the command interpreter.
>
> And some other commands can also run when not logged in.

Also possible in RSX, and used to be possible in RSTS/E prior to V9.

[...]
> The sent in the bug report to DEC.
> There is a box on the bug report, to publish the report.
> Some checked the box.
> And DEC published the bug report before reading it.

Ooops. :-)

> I remember from VMS days, using logical names to run programs
> by name, without a RUN command.

Not logical names, but symbols (like variables) in DCL.

FOO = "DIR/FULL"

for example.

It also works in DCL on RSTS/E.

Logical names is a different namespace. You can put anything you want
there, but you need to explicitly do the translation for a logical name.
That is always done when parsing filenames, but you can do it explicitly
at any point yourself as well.

Johnny

gah4 <gah4@u.washington.edu> writes:
>On Tuesday, August 15, 2023 at 1:51:06=E2=80=AFPM UTC-7, Rich Alderson wrot=
>e:
>
>(snip)
>
>> Tops-10 uses a LOGIN program, invoked by the command interpreter.=20
>
>And some other commands can also run when not logged in.
>
>One of those is QUEUE, useful to see where you are in the print queue
>or batch queue.
>
>Story I remember from the TOPS-10 days, is that QUEUE has the ability to ru=
>n
>another command when it is done. It seems a feature designed to allow a pr=
>ogram
>to run QUEUE, and then restart (continue) itself.
>
>Someone found out that you could run QUEUE when not logged in, and also use
>the ability to run another program. (Which runs on a system account.)
>
>The sent in the bug report to DEC.
>There is a box on the bug report, to publish the report.
>Some checked the box.
>And DEC published the bug report before reading it.
>
>
>I remember from VMS days, using logical names to run programs
>by name, without a RUN command.=20
>

Early versions of VMS installed the DEBUG utility with change mode
to kernel capability. In a student environment it didn't take long
for that misfeature to be abused. It was easily fixed.

Early versions of VMS didn't read-protect the system dump file;
analysis of the typeahead buffers usually showed the system manager
password when they logged in just prior to rebooting. Another one
easily fixed.

On Wednesday, August 16, 2023 at 7:11:00 AM UTC-7, Scott Lurndal wrote:

(snip)

> Early versions of VMS installed the DEBUG utility with change mode
> to kernel capability. In a student environment it didn't take long
> for that misfeature to be abused. It was easily fixed.

> Early versions of VMS didn't read-protect the system dump file;
> analysis of the typeahead buffers usually showed the system manager
> password when they logged in just prior to rebooting. Another one
> easily fixed.

My favorite early VMS oops, is that you could rename a directory into itself.

I think that was:

REN X.DIR [-.X]

The files go away, but quota isn't reduced, and I think the blocks are still in use.

On 2023-08-17 06:45, gah4 wrote:
> On Wednesday, August 16, 2023 at 7:11:00 AM UTC-7, Scott Lurndal wrote:
>
> (snip)
>
>> Early versions of VMS installed the DEBUG utility with change mode
>> to kernel capability. In a student environment it didn't take long
>> for that misfeature to be abused. It was easily fixed.
>
>> Early versions of VMS didn't read-protect the system dump file;
>> analysis of the typeahead buffers usually showed the system manager
>> password when they logged in just prior to rebooting. Another one
>> easily fixed.
>
> My favorite early VMS oops, is that you could rename a directory into itself.
>
> I think that was:
>
> REN X.DIR [-.X]
>
> The files go away, but quota isn't reduced, and I think the blocks are still in use.

Yeah. That would end up as a lost file (the directory), and then all
files beneath that would also be lost.
It can be recovered, but that requires running the disk checking tools.
Similar to fsck.

Same thing can happen/be done in RSX as well.

Johnny

On Sunday, August 20, 2023 at 7:51:35 AM UTC-7, Johnny Billquist wrote:
> On 2023-08-17 06:45, gah4 wrote:

(snip)
> > My favorite early VMS oops, is that you could rename a directory into itself.
> >
> > I think that was:
> >
> > REN X.DIR [-.X]
> >
> > The files go away, but quota isn't reduced, and I think the blocks are still in use.

> Yeah. That would end up as a lost file (the directory), and then all
> files beneath that would also be lost.
> It can be recovered, but that requires running the disk checking tools.
> Similar to fsck.
> Same thing can happen/be done in RSX as well.

I think it doesn't work anymore in VMS, but it did in early versions.

Pretty often in unix, I do:

mkdir newdir
mv * newdir

to move all the files except newdir, and it works fine, though with a message.

As well as I know, the blocks were recovered with disk tools, but they
didn't give me the files back.