Moving buttembler programs above the line 507

re:

sorry, fingerslip ... mft to vs1 ... MVT to svs (not mft to svs).

note however the very next paragraph did get it right

I remember some pok visit where we were in the 706(?) machine room late 3rd shift ... and Ludlow(?) was putting together the AOS2 prototype (what was to become SVS) ... basically MVT with a little bit of glue code to create a single 16mbyte virtual address space (thus the eventualy name SVS ... or single virtual storage ... as opposed to the later MVS ... or multiple virtual storage); in effect, most of MVT just thot it was running in a 16mbyte real machine. The other piece that had to be done for AOS2 was that CCWTRANS was borrowed from CP67 to scan the virtual CCW programs, creating shadow-real channel programs, fixing virtual pages, translating virtual to real addresses, etc.

the actual reason for the pok visit was probably some 370 architecture review board meeting ... but there was also various kinds of technology transfer activities ... educating people in POK about virtual memory technology.

did have some problem with the group doing the page replacement algorithm for SVS (and used well into MVS lifetime). i had done global LRU approximation algorithm as an undergraduate (aka clock-like). The POK performance modeling group had come up with the idea that if the replacement algorithm replaced non-changed pages before selecting changed pages for replacement ... it was more efficient (i.e. you didn't have to write the change page out before taking over the real memory slot). no matter how much i argued against it ... they stead-fastly went ahead and did it any way.

It was well into the MVS life cycle ... that somebody noted that MVS was selecting high-used, shared program pages (aka linkpak, etc) for replacement before they were selecting lower-used, private data pages for replacement.

the clock thing had another aspect

circa 1980 there was a person that wrote their stanford Phd thesis on clock replacement. I had done the original work in the late 60s while an undergraduate ... about the time there was an ACM paper on working set, local LRU replacement, etc. The "clock" stuff was global LRU replacement and there was significant opposition from the "local" LRU forces against granting the stanford Phd (involving global LRU).

however, in the early 70s, there had been a ACM article published by people at the grenoble scientific center on their modifications to CP-67 exactly implementing what was described in the late '60s ACM paper on working set. Grenoble was running cp-67 on 1mbyte 360-67 (154 "pageable" pages after fixed kernel requirements) and a 30-35 CMS intensive workload. At the same time, cambridge scientific center was running CP-67 on a 768kbyte 360-67 (104 "pageable" pages after fixed kernel requirements) and 75-80 CMS intensive workload (avg. CMS use was nearly the same at the two science centers).

The cambridge system with 75-80 users, 104 pageable pages and global LRU implementation had about the same response and thruput as the grenoble system with local LRU implementation with 30-35 users, 154 pageable pages (with the two CMS communities doing nearly same mix of activities). Having the two sets of performance comparison numbers helped break the long jam getting the standford Phd thesis approved.

--