On Fri, 08 Dec 2017 14:36:44 -0500, Dennis Lee Bieber wrote:

> On Fri, 8 Dec 2017 18:07:41 +0000 (UTC), Kiwi User
>  declaimed the following:
>
>>Noted. I started with mainframes in 1968, when what we now call a
>>'partition' was known as a 'diskfile' and allocated and initialised with
>>programs that were equivalent to a partition editor, e.g. parted, and a
>>formatter, e.g. mke2fs. As a concession to programmers, you could store
>>program source in 'subfiles' withing a 'diskfile'
>>
>  Sounds suspiciously like what I know as "partitioned data set" --
of
> which my only exposure was a utility for LS-DOS/TRS-DOS which created a
> file on the disk, said file itself then having an internal directory
> structure containing sub-files (take into account that subdirectories
> were not an OS feature; each disk directory had a limit to the number of
> files it could reference -- a PDS allowed storing lots of small
> application files without using a lot of limited OS directory entries,
> and without lots of wasted partially filled last sectors on the files).
>
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:

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

- there were also proprietary databases (structure depending on whether
  the DB was hierarchic (IBM's IMS was typical) or, a bit later, pointer
  linked systems: Goodyear's IDMS was the archetype, of which ICL's IDMSX
  was a superclass. IDMS was the basis of Codasyl-compliant databases.

This way of handling disk is surprisingly long-lived, certainly
persisting through IB< S/360, 370 and (I think) into System Z.

System/38, which was IBM's Future Series that was killed off in 1971 and
then resurrected as S/38 before becomming the AS/400 series and then the
I-series also used this type of disk management: it basically supported
two disk filing systems:
 - subfiles with a common record length and index structure for all the
   subfiles in a file. Used to store card-image type text files, compiled
   binaries and sets of fixed length indexed records

 - relational databases

The first hierarchical filing system I used was provided by ICL's George
3 mainframe OS. I met that in late 1969 or early 1970 and, give or take a
few strangenesses like automatic incremental backups and the tendency of
unused backed up files to disappear from disk (they automatically
reappeared if you needed them), the G3 filing system was fairly similar
to UNIX filing systems. Unsurprising, since I have a feeling that MULTICS
was a common ancestor.


--
Martin    | martin at
Gregorie  | gregorie
          | dot org

--- SoupGate-Win32 v1.05