I suppose it's fairly natural to assume from the POV of the 3rd decade of the 21st century that computers from 50 years ago had basic facilities like hierarchical directories... but not all of them did.

Big ones like high-end minicomputers did. I learned on VAX/VMS at university in the 1980s, and it did.

Cheap low-end minis didn't, and nor did the early 8-bit machines whose design was inspired by low-end minicomputers.

The main influences on CP/M were DEC OSes: OS/8 and TOPS-10.

https://en.wikipedia.org/wiki/OS/8

https://en.wikipedia.org/wiki/TOPS-10

The 2nd is mentioned here:

https://en.wikipedia.org/wiki/CP/M#Early_history

I have never used either -- I'm not that old -- and I am not sure but I don't think either supported hierarchical subdirectories.

The closest thing that evolved into something that did was the DEC OS RSX-11, which influenced VMS. They used a filesystem called DEC Files-11:

https://en.wikipedia.org/wiki/Files-11

So that did end up supporting hierachical directories, but there isn't a "directory separator" per se. That's a UNIX-ism that MS-DOS 2.0 copied.

A VMS file in its folder might have been called something like:

VAXA$DKA100::[USERS.LPROVEN.SOURCE.FORTRAN]WUMPUS.FOR;42

In other words, devices had multicharacter names that had meaning (e.g. what type of controller board, then which controller, then which disk), possibly after a cluster node name, then in square brackets a folder path separated by dots, then a filename, then another dot, then a 3-letter extension, then a semicolon, then a version number.

Looks baroque compared to the dead simple UNIX name style...

/home/lproven/source/fortran/wumpus

Every time you save a file, the version number increments automatically. And path specs combined with device names and cluster names mean that the filename could point to another disk on this controller, or another disk on a different controller, or a disk on another node in the cluster, or a disk on any node in a named cluster.

You can't do that so easily with the Unix naming system. So the sysadmin has to mount folders from other machines into this one's filesystem, and that means also setting up some kind of distributed authentication like NIS or YP or LDAP, and then some PAM modules or something... and it all gets very complicated.

In other words, the simplicity of the UNIX design doesn't take complexity away: it just hides it. It's still there but it becomes someone else's problem.

Whereas the DEC way of doing things sort of puts the complexity right there in front of you, but in return, you got rich facilities right there.

Much less need for Git when files are versioned and you can go back to an older version before you broke something just using info encoded into the filename. Much less need for NFS mounts when the filesystem knows about controllers and networking and clusters and lets you address them. Much less need for bolted-on fancy authentication when that's built into the OS because the designers thought about stuff like networks, clusters, and authentication, when all that got taken _out_ of UNIX and then had to be bolted back on later.

So, yeah, the UNIX way is simpler, but OTOH that also means it's poorer. Poorer as in less rich. As in the DEC system was richer: being richer lets you do more.

CP/M evolved into multitasking multiuser OSes in time, but DR didn't get to re-invent all this stuff.

Maybe if DOS had never happened, DR would have prospered and bought DEC instead of Compaq buying DEC, and this stuff would have made it into PC OSes.

Who knows...

Not true. On IBM mainframes, options are generally specified in a NAME=VALUE or NAME(VALUE) format. For example, here is a TSO command to allocate a dataset: ALLOCATE DATASET(ALLOC.FILE1) NEW DIR(4) TRACKS SPACE(2,3) DSORG(PO) RECFM(F) LRECL(80) BLKSIZE(800) CATALOG

VM/CMS uses an open parenthesis to introduce options instead, for example: LISTFILE (LABEL

The forward slash option style does not come from IBM mainframes.

Nor (despite what many people think) does it come from CP/M – CP/M's own option style was to put options in square brackets: PIP B:=A:*.COM [G9 V]

Not sure exactly where CP/M gets that from, but may be very vaguely inspired by IBM mainframe conventions (especially VM/CMS), with square brackets replacing parentheses for whatever reason, and using single characters to save memory and typing.

What I actually believe happened: forward slash comes from DEC via Microsoft. Microsoft's development tools for CP/M used that option style, which Microsoft got from DEC, because they didn't like CP/M's native option style. QDOS/PC-DOS/MS-DOS 1.0 copied that Microsoft option style.

Yes, IBM did tell Microsoft not to change it from / to - between PC-DOS 1.0 and PC-DOS 2.0. But that was simply because IBM cared more about backward compatibility between DOS 1.0 and DOS 2.0 than Microsoft themselves did. It was nothing to do with mainframes.

The only thing about DOS which shows any strong direct IBM influence, in terms of actual syntax/terminology/concepts/etc, is code pages.

Most mainframe OSes have flat filesystems which do not have the concept of subdirectories.

They also do not use command switches.

The behaviour was almost certainly inherited from DEC TOPS-10:

http://www.os2museum.com/wp/why-does-windows-really-use-back...

This is not a mainframe OS, or an IBM one either. It ran on a 36-bit DEC minicomputer, the PDP-10.

[1] https://developer.apple.com/library/archive/documentation/ma...