On Fri, 08 Dec 2017 21:45:34 -0500, Dennis Lee Bieber wrote:
> 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)
I'd believe that minis were somewhat different from mainframes. After all
they were a generation later. I did some preliminary design and coding
for a PDP8 job before being yanked off it and sent to NYC in a project
involving an ICL 2903 [1]. But, IIRC the PDP-8 used 8.3 format filenames
in a single directory per disk and had no concept of file ownership - IOW
CM/M, DRDOS, FLEX and MSDOS (before it got directories) filing systems
were virtually direct copies of the venerable PDP-8 filing system.
[1] ICL 2903 was a real wolf in sheep's clothing, being effectively a
small mainframe disguised as a desk-sized office environment computer. It
was actually a 2900 disc file controller running microcode that emulated
a 1900 mainframe, so it ran unmodified 1900 software under a tweaked
version of George 1 OS and supported a variety of greenscreen terminals.
It was programmed in COBOL and RPG, but would run any of the other
compilers - I wrote a single threaded timesharing TP monitor in PLAN 3
assembler for it because 1900 COBOL required subroutine names to be
literal constants.
5-6 years later I did something very similar on a 2900 mainframe, but
this time it was entirely in COBOL because this version supported
variable subroutine names, which meant you could do something like:
01 module-name pic x(20).
...
move "DISP-COMPOSER-DETS to module-name.
call module-name using param-1 param-2 .....
as the procedure dispatcher that lies at the heard of any TP monitor.
--
Martin | martin at
Gregorie | gregorie
| dot org
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | FidoUsenet Gateway (3:770/3)
|