Deutsch   English   Français   Italiano  
<v5c983$11ggu$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!feeds.phibee-telecom.net!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Stephen Fuld" <SFuld@alumni.cmu.edu.invalid>
Newsgroups: comp.arch
Subject: Re: ARM is sort of channeling the IBM 360
Date: Mon, 24 Jun 2024 17:09:24 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 93
Message-ID: <v5c983$11ggu$1@dont-email.me>
References: <s7r87j1c3u6mim0db3ccbdvknvtjr4anu3@4ax.com> <v51tcr$26io$1@gal.iecc.com> <87plsb87hn.fsf@localhost> <v5aggt$j1nj$7@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 24 Jun 2024 19:09:24 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="4f6614dcdb3e9cb48f7388de74d37b88";
	logging-data="1098270"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19JZ5Nz3nYsIcIRh+aNtVFh9iA42glsyOY="
User-Agent: XanaNews/1.21-f3fb89f (x86; Portable ISpell)
Cancel-Lock: sha1:/tWBK3nBYgJxSmyPtsbABai+6MU=
Bytes: 4149

Lawrence D'Oliveiro wrote:

> On Thu, 20 Jun 2024 14:28:04 -1000, Lynn Wheeler wrote:
> 
> > a little over decade ago was asked to track down decision to add
> > virtual memory to all 370s. basically MVT storage management was so
> > bad that required specifying region storage requirements four times
> > larger than used ...
> 
> Let me see if I got this straight.


You're close.


> 
> In the early days, the offshoots of OS/360 were “MFT” (“Multiple
> Fixed Tasks”) 


"Multiprogramming with a Fixed number of Tasks"


and “MVT” (“Multiple Variable Tasks”).


"Multiprogramming with a Variable number of Tasks"



> The “Multiple”
> part had to do with this new-fangled thing called “multiprogramming”:
> basically, there was so much RAM available by that point that you
> could typically keep multiple programs memory-resident at once, even
> if only one was executing, instead of having to swap everybody but
> the current program out.


Right.  So you could make productive use of the CPU while one program
was idle, typically waiting for an I/O.



> The difference was, with MFT, a program had to declare its memory 
> requirement before it could be started, and the only way to change
> that was to stop the program and start it again. Whereas MVT allowed
> a program to change its memory requirements while it was executing.
> (Whoah! Program relocation requirement styleee!)


Not quite.  With MFT, the system operator defined the numbeer and size
of each region of memory.  For example, a site may have two partitions
of 3MB and one of 6MB.  These were rarely changed.  It was the
operator's responsibility to try to maximize system usage by starting
jobs in the appropriate sized partitions.  With MVT, there were no
fixed sized partitions.  The memory requirements for each job were
specified by the job and again, it was the operator's responsibility to
try to maximize usage.

While a job could change its memory requirements with each task,IIRC it
was better to specify the largest requirement in the beginning, and
releasing memory as the largest remaining requirement got smaller.
This was because if the memory requirement increased inn the middle of
the job, you were not quaranteed that the additional memory was
available, and if it wasn't, the job would have to be terminated or
"rolled out" until the required memory was available.  Note, as John
explained, since programs were not relocatable, if a program was rolled
out, it could only be rolled in to the same address it was rolled out
from.



> 
> Then, when virtual memory came along, MFT became OS/VS1, while MVT
> became OS/VS2.
> 
> Eventually, the MFT→OS/VS1 line died a long-overdue death, and OS/VS2 
> became “MVS”. Not sure what other name changes happened along the
> way, but nowadays this is known as “z/OS”.


Right.

> 
> Does that make sense?

Close.



-- 
 - Stephen Fuld 
(e-mail address disguised to prevent spam)