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)