Path: ...!npeer.as286.net!npeer-ng0.as286.net!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Lynn Wheeler <lynn@garlic.com>
Newsgroups: comp.arch
Subject: Re: ancient OS history, ARM is sort of channeling the IBM 360
Date: Sun, 30 Jun 2024 08:58:22 -1000
Organization: Wheeler&Wheeler
Lines: 67
Message-ID: <87frsumf5d.fsf@localhost>
References: <87ed8e7os5.fsf@localhost>
	<memo.20240630105046.956Z@jgd.cix.co.uk>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Sun, 30 Jun 2024 20:58:24 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a7d4b7a17d1bcfd540865bbd0b7e063f";
	logging-data="696443"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18U6mFV1fpcrWmbOb+SQuRo0AphQWSQRHE="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:WYSpTOgp6X0+bBhxX6Zcd2A658U=
	sha1:vyqA+lGk2ZtDvRTeyC7iMPNAwrc=
Bytes: 4882

jgd@cix.co.uk (John Dallman) writes:
> What was the problem with the memory management? My experience of systems
> without virtual memory doesn't include any that shared the machine among
> several applications, so I have trouble guessing.  

os/360 had "relative" (fixed) adcons ... that were resolved to fixed
(real) address at initial program load (and couldn't change for the
duration of the program) ... that also presented downside when moving to
virtual memory paged environment ... could directly execute paged image
from disk ... first, executable image had to be preloaded and all
"relative' adcons modified for the specific instance. tss/360 had
addressed that by keeping relative adcons, "relative" to base kept in
data structure specifically for that instant (same paged shared
executable image could appear at different addresses for different
programs executing in different address spaces).

MVT memory management for dynamic allocation for data had horrendous
problem with storage fragmentation and frequent requirement for large
areass of contiguous storage. Storage fragmentation problem increased
the longer the programs were running (and maintaining contiguous
allocation as number of different, concurrently running regions
increased). After joining IBM, I had done a page mapped filesystem for
CMS and because CMS made extensive use of OS/360 compilers, I was
constantly fighting the OS/360 adcon convention (wanting to constantly
prefix ADCONs as part of executable loading).

note before I had graduated, I had been hired fulltime into small group
in the Boeing CFO office to help with the formation of Boeing Computer
Services (consolidate all data processing into an independent busines
unit). I thot Renton datacenter possibly largest in the world (couple
hundred million in IBM 360s, sort of precursor to modern cloud
megadatacenters), 360/65s arriving faster than could be installed, boxes
constantly being staged in the hallways around the machine room. Lots of
politics between Renton director and CFO who only had a 360/30 up at
Boeing field for payroll (although they enlarged the room to install a
360/67 for me to play with when I wasn't doing other stuff).

While I was there they moved a two-processor, duplex 360/67
(originally for tss/36) up to Seattle from Boeing Huntsville.
Huntsville had got the two processor machine with lots of 2250 graphic
screens
https://en.wikipedia.org/wiki/IBM_2250

for (long running) CAD 2250 applications ... since tss/360 didn't have
any CAD support ... they configured it as two single processor systems
each running MVT13 ... which was severely affected by the fragmentation
problem that increased the longer each CAD 2250 program was running. A
few years before the decision was made to add virtual memory to all 370s
.... Boeing Huntsville had modified MVT13 to run in virtual memory mode
.... it didn't support paging ... but used the virtual memory to create
contiguous virtual memory areas out of non-contiguous areas of real
storage (to address the MVT storage management problem).

the initial solution adding virtual memory to all 370s (VS2/SVS) was to
continue allow each executing region to continue specifying/reserving
large, contiguous storage area ... but support paging and increase the
number of concurrently executing regions.

The original OS/360 design point of running in small real storage
contributed to the excessive disk activity ... where lots of system was
fragmented into small pieces that would be sequentially loaded from disk
for execution ... and then increasing the number of concurrently
executing regions used to compensate for the large I/O disk filesystem
wait time (somewhat analogous to processor poor cache hit rate)

-- 
virtualization experience starting Jan1968, online at home since Mar1970