The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[EMAIL PROTECTED] (Ed Gould) writes: > It would be interesting, I would think to have the "old timers" > compare the code that was used in the "old days" against what is used > today. > > The code I think has been recoded many a time. Do you think the new > people could show the old people new tricks or would it be the other > way around? some of this cropped up during the early days of os/vs2 svs development. at the time, cp67 was one of the few relatively succesful operating systems that supported virtual memory, paging, etc (at least in the ibm camp). as a result some of the people working on os/vs2 svs was looking at pieces of cp67 for example. one of the big issues facing transition from real memory mvt to virtual memory environment was what to do about channel programs. in virtual machine environment, the guest operating system invokes channel programs ... that have virtual addresses. channel operation runs asyncronously with real addresses. as a result, cp67 had a lot of code (module CCWTRANs) to create an exact replica of the virtual channel program ... but with real addresses (along with fixing the associated virtual pages at real addresses for the duration of i/o operation). these were "shadow" channel programs. svs had a compareable problem with channel programs generated in the application space and passing the address to the kernel with EXCP/SVC0. the svs kernel now was faced with also scanning the virtual channel program and created a replica/shadow version using real addreses. the initial work involved taking CCWTRANS from cp67 and crafting it into the said of the SVS development effort. one of the other issues was that the POK performance modeling group got involved in doing low-level event modeling of os/vs2 paging operations. one of their conclusions ... which I argued with them about ... was that replacing non-changed pages was more efficient than selecting a change page for replacement. no matter how much arguing they were adament that on a page fault ... for a missing page ... the page replacement algorithm should look for a non-changed page to be replaced (rather than a changed page). This reasoning was that replacing a non-changed page took significantly less effort (there was no writing out required for the current page). the issue is that in LRU (least recently used) page replacement strategy ... you are looking to replace pages that have the least likelyhood of being used in the near future. the non-changed/changed strategy resulted in less weight being placed on whether the page would be needed in the near future. this strategy went into svs and continued into the very late 70s (with mvs) before it was corrected. finally it dawned on somebody that the non-changed/changed strategy resulted in replacing relatively high-use, comonly used linkpack executable (non-changed) pages before more lightly referenced, private application data (changed) pages. these days there is a lot of trade-off trying to move data between memory in really large block transfers .... and using excess electronic memory to compensate for disk i/o bottlenecks. in the vs1 handshaking scenario ... vs1 letting vm do its paging in 4k blocks was frequently signifantly more efficient than paging in 2k blocks (made less efficient use of real storage, but it was a reasonable trade-off since there was effectively mode real storage resources than there were disk i/o access resources). later "big pages" went to 40k (10 4k page) 3380 track demand page transfers. vm/hpo3.4 would typically do more total 4k transfers than vm/hpo3.2 (for the same workload and thruput) ... however, it could do the transfers with much fewer disk accesses; it made less efficient use of real storage, but more efficient use of disk i/o accesses (again trading off real storage resource efficiency for disk i/o resource efficiency). ... or somewhat reminiscent of a line that I started using as an undergraduate in conunction with dynamic adaptive scheduling; "schedule to the (system thruput) bottleneck". misc. past posts mentioning past dynamic adaptive scheduling work and/or the resource manager http://www.garlic.com/~lynn/subtopic.html#fairshare previous posts in this thread: http://www.garlic.com/~lynn/2006r.html#34 REAL memory column in SDSF http://www.garlic.com/~lynn/2006r.html#35 REAL memory column in SDSF http://www.garlic.com/~lynn/2006r.html#36 REAL memory column in SDSF http://www.garlic.com/~lynn/2006r.html#37 REAL memory column in SDSF misc past posts mentioning os/vs2 starting out using CCWTRANS from cp67 http://www.garlic.com/~lynn/2000.html#68 Mainframe operating systems http://www.garlic.com/~lynn/2000c.html#34 What level of computer is needed for a computer to Love? http://www.garlic.com/~lynn/2001l.html#36 History http://www.garlic.com/~lynn/2002n.html#62 PLX http://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill http://www.garlic.com/~lynn/2003g.html#13 Page Table - per OS/Process http://www.garlic.com/~lynn/2003g.html#14 Page Table - per OS/Process http://www.garlic.com/~lynn/2004c.html#59 real multi-tasking, multi-programming http://www.garlic.com/~lynn/2004e.html#40 Infiniband - practicalities for small clusters http://www.garlic.com/~lynn/2004n.html#26 PCIe as a chip-to-chip interconnect http://www.garlic.com/~lynn/2004n.html#54 CKD Disks? http://www.garlic.com/~lynn/2004o.html#57 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2005b.html#49 The mid-seventies SHARE survey http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line http://www.garlic.com/~lynn/2005f.html#47 Moving assembler programs above the line http://www.garlic.com/~lynn/2005p.html#18 address space http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3 http://www.garlic.com/~lynn/2005q.html#41 Instruction Set Enhancement Idea http://www.garlic.com/~lynn/2005t.html#7 2nd level install - duplicate volsers http://www.garlic.com/~lynn/2006b.html#25 Multiple address spaces http://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT http://www.garlic.com/~lynn/2006i.html#33 virtual memory http://www.garlic.com/~lynn/2006j.html#5 virtual memory http://www.garlic.com/~lynn/2006j.html#27 virtual memory http://www.garlic.com/~lynn/2006m.html#25 Mainframe Limericks http://www.garlic.com/~lynn/2006o.html#27 oops ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
