Include path question

[CBFalconer]

.... snip ...

And perhaps most important, there was no standardized way of
specifying "the config.h file in user area 5" by some kind of path
name. CP/M didn't provide a way of translating a text "path name"
into a FCB, so although it was possible to invent a syntax for such
a "path name", every application that wanted to use such a thing
had to be aware of the syntax or use a library that was, and it
wouldn't work for applications written before that feature was
introduced.

You obviously never used either ZCPR or my DOS+ system. Both had
DU addressing, whereby the file location could be described as
"B8:filename.typ", for example. My CCP+ (not sure about ZCPR) had
paths for executables, and (memory hazy) possibly for data.
CP/M2.2 documentation claimed that any user could execute programs
with the sys attribute in user area 0, but it didn't do it. DOS+
did. Together with the executables path, and the extension to
loading executables from COMMAND.LBR, this allowed much to be
packed into a small space and fairly good control of user
capabilities.

 

[Leor Zolman]

I'm reasonably sure they weren't present in CP/M 2.0, which is why
I said CP/M 2.0. The "sub-areas" didn't increase the number of
files you could fit on a floppy. "user 0" was special. A "user
0" file appeared in all "sub-areas", and a program running as "user
0" saw only "user 0" files.

And perhaps most important, there was no standardized way of
specifying "the config.h file in user area 5" by some kind of path
name. CP/M didn't provide a way of translating a text "path name"
into a FCB, so although it was possible to invent a syntax for such
a "path name", every application that wanted to use such a thing
had to be aware of the syntax or use a library that was, and it
wouldn't work for applications written before that feature was
introduced.

Well, I did add user-area prefix recognition to the BDS C filename
syntax when user areas came out... so at least there was a "standard"
way of doing it under *that* platform...
-leor

 

[Gordon Burditt]

And perhaps most important, there was no standardized way of

You obviously never used either ZCPR or my DOS+ system. Both had
DU addressing, whereby the file location could be described as
"B8:filename.typ", for example. My CCP+ (not sure about ZCPR) had
paths for executables, and (memory hazy) possibly for data.

That's great, now if only it could have been made to work for stuff
like the standard text editor, so you don't have the situation that
B8:filename.typ works on your system, fails with an error on some
other programs, or worse, since error-checking was never a strong
point of CP/M programs, quietly use B:filename.typ in the current
user area instead, or something else. There's a lot to be said for
consistency.

I remember seeing *at least*:
<drive><user>:filename.typ
<drive>:filename.typ;<user>
<drive>:filename.typ.<user>

and the user number wasn't always in decimal.

 

[Walter Roberson]

Sorry but MVS has never had an association between a "logical disk"
and a letter. IBM has several different operation systems and a
different one may have something similar to what you describe.

Rechecking, it appears I was referring to CMS.

I very briefly investigated MVS last night; found a bunch of
unrelated T-shirt importation places, and lots of repetitions of
sites that didn't say anything much useful. I did find that
MVS's component specifiers are a convention rather than an
actual grouping.

What I was not able to determine within a reasonable time, though,
was exactly what an MVS catalog is. I could see that there was more
than one, including a critical "master catalog", and I could see
a few utilities such as LISTCAT that would list the catalog given
a project code.

It -appeared-, with the little hard data that I could find, that an MVS
catalog was arguably a "directory" within the meaning given by an
earlier poster. I did see a hint that catalogs did not really
organize the storage, and instead merely provided more convenient
ways to go between readable names and internal dataset serial numbers,
but if that is the case then it could be argued that a catalog entry
was akin to a traditional Unix directory entry, which merely associates
a name and an inode number with all the real action happening
at the inode level. None of this was really very clear in what I found.

 

[Jalapeno]

What I was not able to determine within a reasonable time, though,
was exactly what an MVS catalog is. I could see that there was more
than one, including a critical "master catalog", and I could see
a few utilities such as LISTCAT that would list the catalog given
a project code.

It -appeared-, with the little hard data that I could find, that an MVS
catalog was arguably a "directory" within the meaning given by an
earlier poster.

Not from an application programming perspective. You are barking up the
wrong tree if you are trying to find "directories" in MVS.

(hint #1: look up HFS).

(hint #2: http://www.redbooks.ibm.com/redbooks/SG245482.html read the
first paragraph of section 1.1 HFS Overview)

 

[Jalapeno]

the real world is not bound by the limitations of your knowledge. The
IBM MVS operating system, currently marketed under the name z/OS does
not have directories.

While true, you can, however, create HFS data sets that are organized
with a tree-like structure using directories via USS (Unix Systems
Services). From a C program, luckily, your file structure (whether it
is PDS, Physical Sequential, or VSAM or whatever) looks like a stream
and the details aren't necessary. If you are writing a program that
_needs_ to know these details then, it's off-topic here ) (I am
pretty sure you know all this Barry. Sometimes MVS people forget about
USS in MVS.)

 

[Dave Thompson]

On 28 Oct 2006 15:20:20 -0700, "Ancient_Hacker" <[email protected]>
wrote:

Well I agree that 99.9% of computers out there have OS's with the
concept of "directories". By which you probably mean the ability to
create multiple, named directories. And without the intervention of
the system operator.

But there have been plenty of OS's without that concept. Even OS's for
$12M computers. Most OS's before 1970 or so <snip>
The concept of tree-structured directories didnt get popular until Unix
V6 and MSDOS 2.0 came out.

MULTICS was definitely several years earlier; TOPS-20 was TTBOMR about
concurrent with first Unix, and TENEX several years earlier.

OS/360 had hierarchically organized _names_, stored centrally in a
system catalog not in separate directories, by the mid '60s. And it
was more widely used and known/taught than the others combined.

But if you mean 'popular' in the sense of used (directly) by large
numbers of people, that would indeed be MSDOS; those others ran on
systems an ordinary person couldn't afford.

But to Walter Roberson downthread, the S/370 et seq system with
"logical disk" with 1letter* 8char-filename 8char-filetype is _CMS_
(run under VM) NOT MVS or any other flavor of OS/* now z/OS.
(* Technically IIRC 1letter disk and optional 1digit mode, but the
latter is rarely needed or used.)

And although it's a debatable point of terminology, I would say that
any centralized metadata mapping names to storage (regions) is a
directory, including CMS, RT-11, and early CP/M or MSDOS; where
necessary I would call this a "one-level" or "fixed" directory in
contrast to "hierarchical" and/or "user-defined" directories. For a
truly nondirectory structure I would point to IBM partitioned data
sets (PDS); Unix (originally) "ar" and "tar" archives; and the alltime
classic, labelled magtapes. Note not ZIP; it has metadata both
distributed AND centralized, and so counts as directoried.

- David.Thompson1 at worldnet.att.net