TIP: Click on subject to list as thread! ANSI
echo: rberrypi
to: DENNIS LEE BIEBER
from: KIWI USER
date: 2017-12-09 15:55:00
subject: Re: RPi3B, /Boot resize,

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)

SOURCE: echomail via QWK@docsplace.org

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.