On Friday, May 1, 2015 at 7:40:11 PM UTC+5:30, Scott Lurndal wrote:
> Anne & Lynn Wheeler <ly...@garlic.com> writes:
> >hanc...@bbs.cpcn.com writes:
> >> In my humble opinion, the single level store, as implemented on the
> >> AS/400, was not easy to use. (Perhaps I was prejudiced being used to
> >> MVS).
> >
> >re:
> >http://www.garlic.com/~lynn/2015c.html#105 IBM System/32, System/34 implementation technology?
> >http://www.garlic.com/~lynn/2015c.html#106 IBM System/32, System/34 implementation technology?
> >http://www.garlic.com/~lynn/2015c.html#110 IBM System/32, System/34 implementation technology?
> >
> >OS/360 and MVS had filesystem mapped to drive ... so had all the issues
> >with managing large number of drives. single level store obfuscated all
> >that treating all disk space as one large pool (but enormously
> >complicating recovery from single drive failure).
> >
> The burroughs medium systems had disk and pack pooling from
> the start. An individual drive configured for 100-byte sectors
> (called DISK) would be part of one of up to 8 "Disk Subsystems" (the
> subsystem number selected the allocation pool to use). One of the
> disk subsystems was reserved for the MCP and associated data files;
> one was typically marked default (for use by applications that didn't
> explicitly specify which subsystem to use for allocation).
>
> A bit later, 180-byte sector media was also supported. This was called
> PACK. One or more packs could be concatenated (like modern RAID-0) into
> a multi-pack "Family". An application would specify the family name
> and the MCP would handle allocation across the set of units in that
> family. One could configure a "resource" family that would be selected
> when the family name was blank or the generic "PACK".
>
> A file could have up to 100 "areas" allocated on a family or
> subsystem. The size of the area depended on the record size,
> blocking factor and blocks-per-area parameters specified when
> the file was created.
>
> Given that the size of an area will differ from file to file,
> checkerboarding was a problem. The SQUASH utility would be
> run if fragementation got too bad and would move areas around
> to create larger units of free-space. The PACK SQUASH utility
> was written in COBOL :-)
>
> scott
Very Nice Information
Thanks for sharing with us
https://paradigm.in/structural-design/
https://paradigm.in/geotechnical-design/
https://paradigm.in/bim-services/
https://paradigm.in/structural-steel-fabrication-drawings/
https://paradigm.in/reinforcement-steel-detailing/
https://paradigm.in/preconstruction-cad-services/

On 3/7/2022 2:35, alexander george wrote:
> On Friday, May 1, 2015 at 7:40:11 PM UTC+5:30, Scott Lurndal wrote:
>> Anne& Lynn Wheeler<ly...@garlic.com> writes:
>>> hanc...@bbs.cpcn.com writes:
>>>> In my humble opinion, the single level store, as implemented on the
>>>> AS/400, was not easy to use. (Perhaps I was prejudiced being used to
>>>> MVS).
>>>
>>> re:
>>> http://www.garlic.com/~lynn/2015c.html#105 IBM System/32, System/34 implementation technology?
>>> http://www.garlic.com/~lynn/2015c.html#106 IBM System/32, System/34 implementation technology?
>>> http://www.garlic.com/~lynn/2015c.html#110 IBM System/32, System/34 implementation technology?

I still have an IBM System/23 in my cellar. It operates, as far as I
know. Numbers come up on the screen when booted. It has it's original
dot-matrix style printer as well. All of the documentation seems to be
there, but I never learned to use the thing.