Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Anne & Lynn Wheeler Newsgroups: alt.folklore.computers Subject: Re: You count as an old-timer if (was Re: Origin of the phrase "XYZZY") Date: Mon, 14 Mar 2016 19:31:35 -0700 Organization: Wheeler&Wheeler Lines: 147 Message-ID: <87fuvs4gl4.fsf@garlic.com> References: <79s9m8$lqh$1@nnrp1.dejanews.com> <79v589$6vf$1@nnrp1.dejanews.com> <36C2D90A.2CC6D420@trailing-edge.com> <7a1n71$kpf@nnrp2.farm.idt.net> <7a1v4p$mdi$1@nnrp1.dejanews.com> <36C55BB5.1F16DCBD@tnglwood.demon.co.uk> <8a7a1cfd-a80e-4723-ad46-a33da2e5f56e@googlegroups.com> <16m4ebpgco28bt6d5t8bj2qt0ah7urpo9h@4ax.com> <1f5de20f-5ed5-4ebc-ba13-bf034ccd8abb@googlegroups.com> <2b76adee-9e0a-457c-9762-950d2b2e226a@googlegroups.com> <87k2l44msb.fsf@garlic.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="9a6c8ce24fcd2caeb84dd64e0fa6007c"; logging-data="4782"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18iCEXK2ekjzMlbU9AjcLgCFAYiPYa3nkk=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) Cancel-Lock: sha1:NjHWhfBHRDDzN0a53Ll7WnV6L+s= sha1:wa5W7Rt/l1sZf3rnHYmnMhR0zSU= Xref: csiph.com alt.folklore.computers:160994 Jon Elson writes: > The problem with 360's (and early 370's without DAT) was that programs > were totally relocatable at load time, but as soon as you executed a > few instructions, physical addresses ("pointers") and subroutine > return addresses were stored in registers and memory locations, and > the program could no longer be relocated. Not a big problem in the > smallest machines, but in larger machines, and especially when on-line > programming like TSO came into favor, you could have many hundreds of > programs in some stage of work. Without the /67's relocation feature, > swapping programs in and out of memory was essentially impossible, as > it would have to be swapped back into the same address as it had been > in before. > > For the 360/67, IBM provided a very hacked OS called CP/67. Mostly > they had to make every system service handle converting any addresses > included as parameters from program space-relative addresses to > physical addresses before the supervisor-state routines could work > correctly. Not a terribly hard job, but required a huge amount of > code to be changed. Also, no I/O could be left hanging when a program > was swapped out. APL/360 swapped workspaces because workspace contents were all interpreted ... no 360 address fields. 360/67 had segment and page tables ... 1mbyte segements and psw-mode controlled whether it was 24bit (16mbyte) or 32bit (4gbyte) addressing (and tables). os/360 "relocatable" were RLD records which gave location of the address constant within the program that had to be "swizzled" after loading but before execution could begin. Official system for 360/67 was tss/360 ... which created location independent execution image. Address space tables could be setup to point to the executable image on disk ... and at arbitrary, dynamically chosen virtual address ... w/o having to preload the image and swizzle all the RLD address constant. science center did (virtual memory) cp/40 and cms on 360/40 that had been modified with virtual memory hardware. cms ran "stand-alone" on 360/40 in standard 360 mode. CMS was developed in parallel with development of cp/40 ... and some of it reflected the experience that many had on MIT's CTSS (some of the CTSS went to the 5th flr and did multics and others went to the science center on the 4th flr) CTSS reference https://en.wikipedia.org/wiki/Compatible_Time-Sharing_System cp/40 history http://www.garlic.com/~lynn/cp40seas1982.txt past posts mentioning the science center http://www.garlic.com/~lynn/subtopic.html#545tech when science center is able to replace their modified 360/40 with 360/67, cp/40 morphs into cp/67. Melinda has a lot more of that history ("VM History" about half-way down) http://www.leeandmelindavarian.com/Melinda/ One of the issues with CMS, was the science center adopted a lot of os/360 applications ... and needed to provide os/360 system services simulation in CMS ... and also acquired a lot of os/360 RLD address constant conventions. Every CMS had its own virtual address space and ran in a 360 virtual machine doing I/O with SIOs and channel programs (ran the same way on stand alone 360/40 as it did in cp/40 or cp/67 virtual machine). It did do a executable image that had all the ADCONS pre-swizzled ... but it resulted in them having to be loaded a fixed address. Jan1968, three people came out and installed CP/67 at university where I was undergraduate. Over the next several months, I rewrote large parts of the CP/67 kernel code (including significantly reducing pathlengths) ... and presented some results at the '68 SHARE meeting ... part of that presentation: http://www.garlic.com/~lynn/97.html#22 Pre S/360 IBM Operating Systems? I also did dynamic adaptive resource management, added TTY terminal support, added order-seek disk arm queuing, dynamically chaining multi-I/O requests in single channel program for disks and 2301 drum (2301 optimized for maximum transfer per revolution), and redid the page replacement algorithm and page thrasing control operation. some posts http://www.garlic.com/~lynn/subtopic.html#fairshare and http://www.garlic.com/~lynn/subtopic.html#wsclock After graduating and joining the science center ... I did a paged-mapped filesystem for CMS ... which had significantly higher throughput than the standard CMS filesystem ... some past posts http://www.garlic.com/~lynn/submain.html#mmap I also redid the CP/67 shared segment infrastructure ... so that could dynamically have multiple shared things at arbitrary locations in the virtual address space. Standard CMS executables transferred from standard filesystem to page mapped filesystem would have to be mapped at the pre-established fixed virtual address. For code to reside in shared segment (appear concurrently at different virtual address spaces) I usually had to do some amount of rewrite. For typical code that would be address independent (similar to tss/360), i usually had to do a whole lot more work. Lots of past posts about pain to get location independent and/or shared code for CMS http://www.garlic.com/~lynn/submain.html#adcon Note that for CP/67 virtual machine SIO ... CCWTRANS would scan the channel program in the virtual machine, fixing/pinning the virtual pages involved in the I/O in real storage, and creating a copy of the channel program with the real page addresses (as opposed to the virtual page addresses), start the I/O with the copy channel program and when it finishes, "unpin" the virtual pages. When they did OS/360 MVT for virtual memory OS/VS2 SVS, they initially borrowed CP/67's CCWTRANS and worked it into EXCP/SVC0 processing. MVT moving to virtual memory had to accept application channel programs built in virtual address space and passed in EXCP/SVC0 and do the same processing that CP/67 did for virtual machine SIO operation. That was by far the biggest amount of code that tehy needed in going from MVT to OS/VS2 SVS (OS/VS2 SVS startup would build a single 16mbyte virtual address space and fix MVT to believe it was running on 16mbyte real machine, then there was a little bit of code to handle page fault, page replacement and page i/o operation). Note: since virtual memory was handled on individual 4k page basis, tasks could be dropped from queue and its pages replaced by some other activated task while I/O simulation was in progress (only the virtual pages actually involved in I/O were fixed, and they would be unpinned and become available as soon as i/o completed) ... dropping from queue can be done whether or not there was simulated I/O in progress. During the early 70s, there was the internal Future System effort that was completely different than 360/370 and was going to completely replace it. http://www.garlic.com/~lynn/submain.html#futuresys I continued to work on CP/67 and would periodically ridicule FS. Part of this FS was doing some of the worst of tss/360 "single-level-store" and I would claim that I learned what not to do for my page-mapped CMS filesystem from IBM SE that would play with tss/360 at the univ (even tho tss/360 did location independent executable images correctly). During FS they were killing off 370 efforts, which is credited with giving clone processors market foothold. When FS implodes, there is made rush to get stuff back into 370 product pipelines ... which contributes to decision to release a lot of stuff I had been doing. Old email about having migrated my stuff from cp67 to vm370 http://www.garlic.com/~lynn/2006v.html#email731212 http://www.garlic.com/~lynn/2006w.html#email750102 http://www.garlic.com/~lynn/2006w.html#email750430 -- virtualization experience starting Jan1968, online at home since Mar1970