On Fri, 8 Dec 2017 23:48:19 +0000 (UTC), Kiwi User
 declaimed the following:

>I was an ICL guy back then, but talking to other 'foreign' mainframers
>made me think that almost all mainframes handled their disks this way.
>There were weren't many things you could do with a disk allocation once
>you'd claimed and named it:
>

 I'd have to dig up my manuals (in a storage locker) for Xerox
Sigma/CP-V... From my college days I don't recall ever having to consider
disk /drives/. An account just had some directory on the disk, and one
could access files of another account by providing that account as a part
of the file name ( filename -- no extensions in use;
college practice was to prefix filenames with S:, R:, and L: for Source,
Relocatable object module [ROM], and Load Module [for some reason LMN]).

 
>- you could read and write it sequentially pretty much as though it was
>  magnetic tape
>
>- you could format it as a random file and treat it as a set of
>  fixed-length, self-indexed records, i.e. the record number was the
>  index. I don't recall whether the record size had to be a submultiple
>  of the block size because I don't ever remember using a random file.
>
>- you could format it as an indexed file. Records were fixed length
>  submultiples of the block size. The file could extend over more than
>  one disk and had three index levels arranged as a tree structure:
>    file level (indexing partitions)
>    partition level (indexing tracks in the partition)
>    track-level (indexing records in that track)
>
>- you could set up a subfile structure to hold source code (usually
>  stored as card images), which had a subfile index and put no
>  restrictions on the subfile size or content except that they all had
>  to fit in the fixed size 'file'
>

 CP-V supported three file organizations: consecutive (and possibly
contiguous) -- your common UNIX stream file; indexed (aka: keyed --
multilevel alphanumeric key, in a way the most common file format as the
text editor used the key for line number [one normally set the editor to
increment by 10, with periodic renumbering] and the FORTRAN-IV run-time
used it for direct access -- index=> record number); and last, random,
which was just that -- one specified the size of the file on creation and
was given that much contiguous disk space, one had total control over the
content, the OS did nothing but treat the file as a unit.

 CP-V also had four I/O modes: read, write, update, scratch. The first
two are as expected, the last two relied up having two current I/O
pointers: read position and write position; update required reading one or
more records before (over)writing, scratch required writing one or more
records before reading back. No equivalent of C's seek(). (Random
organization probably supported seek, but not the OS managed files)

--
 Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

--- SoupGate-Win32 v1.05