Chip Davis wrote:
... when shared segments were implemented in VM. It seems to me that it predated the VM/370 SEPP/BSEPP days when I started, but there's been many a synapse lost since then. Google, Wikipedia, ibm.com, and even Melinda's wonderful work have not been revealing, so I thought perhaps might be an old gray-beard like myself (with a better memory) still reading this list. Any help?
CP67 had "named systems" ... basically page image was "saved" to reserved location and the "IPL" command would map the "saved" portion of virtual memory to those saved pages on disk. Used originally for CMS. 360/67 segment (sharing) only offered 1mbyte segments ... and CMS was much smaller than 1mbyte ... in fact standard CMS virtual machines were 256kbytes and CMS "kernel" (low core address) was something like the first 18 pages. So something as a result ... CMS had 3 shared pages ... that were "locked" into real storage ... every virtual memory page table (for "named" CMS) had same 3 virtual page table entries pointing to the same (locked) real pages. To provide read-only protection of those three pages, CP67 played special games with the 360 storage protect keys. Moving to 370, original 370 virtual memory architecture (defined in the 370 "red book" ... the "red book" was cms script file with command line options would print the full architecture book ... or just the principles of operation subset) had 64kbyte segment options and 1mbyte segment options. For 370, CMS was restructured to have the 1st 64k non-shared & data, and the 2nd 64k "shared" ... using the 370 64kbyte shared segment facility. The original 370 virtual memory architecture also had R/O segment protect facility ... bit defined in each virtual memory segment table which would provide R/O segment protection. vm370 was initially implemented to use this facility for protecting shared pages. The mechanism was still the defined named systems and invoked/used via the ipl-by-name facility. the retrofit of virtual memory hardware to 370/165 ran into delays and at one point there was suggestion to drop a lot of the 370 virtual memory features in order to buy back six months in the scheduled (and not slip the 370 virtual memory announcement by six months). One of the features that got dropped was "segment protect". As a result, all the other hardware implementations had to go back and remove all the features dropped by the 165 implementation ... and vm370 had to return to the (kludge) r/o page protection mechanism using the 360 key protect mechanism (from cp67) ... but for whole segments. I was at the science center ... past posts mentioning science center http://www.garlic.com/~lynn/subtopic.html#545tech and we were still running with 360/67 and doing lots of enhancements to cp67. One of the features was a page-mapped filesystem faciilty for cms. This eliminated a whole lot of I/O simulation overhead and pathlength (even compared to diagnose I/O ... a form of which I had originally done as undergraduate) and opened up the ability to do a whole lot more interesting things using virtual memory (basically allowing page mapped views of anything done as part of standard cms "file" operations ... not just restricted to ipl-by-name). Misc. past posts mentioning page-mapped work for cms filesystem http://www.garlic.com/~lynn/subtopic.html#mmap Eventually, science center was slated for getting at 370/155 and I had to look at moving lots of my cp67 work to vm370 ... old memo on the subject http://www.garlic.com/~lynn/lhwemail.html#email731212 and a couple describing having done the work (and what was in the "csc/vm" distribution system) http://www.garlic.com/~lynn/2006w.html#email750102 http://www.garlic.com/~lynn/2006w.html#email750430 one of my hobbies had been providing highly modified cp67 systems to internal locations (sort of my own product distribution). that dropped off as some number of internal locations moved from cp67 to vm370 ... but really took off when I had moved from cp67 to vm370. One of my major hobby/customers was the HONE system ... lots of past posts http://www.garlic.com/~lynn/subtopic.html#hone HONE had been created after the 23jun69 unbundling announcement ... originally cp67 virtual machine systems originally targeted at giving branch office SEs "hands-on" to operating systems running in virtual machines. The HONE system even got special CP67 modifications that simulated the initial new instructions in 370 ... allowing running/testing of 370 operating systems that used the new instructions (i.e. allowing them to run in virtual machine under cp67 on 360/67. The science center had also ported apl\360 to cp67 cms for cms\apl. A lot of sales & marketing support applications were developed in APL and started to be offered to sales & marketing. Eventually that use came to dominate HONE activity and the virtual machine experience for branch office SEs evaporated. APL had been restructured to "shared memory" operations and originally HONE had a special "ipl-by-name" APL ... which put sales&marketing into APL only environment. However, there was some requirement to have non-APL applications to be run ... and it was extremely awkward to have sales & marketing people issue the IPL command to switch between APL and non-APL applications. So one of the first big uses of page-mapped filesystem and new shared segment mechanism was HONE APL use with early flavor of CSC/VM). Whether or not a page-mapped file was loaded as non-shared or shared ... were new parameters that could be specified when the module was "generated" (genmod) ... and supported by kernel program loading facility. Many of the internal 370 organizations slacked off on product development during the height of future system activity (since future system was going to replace all 360 & 370 ... and was significantly different that 360/370) http://www.garlic.com/~lynn/subtopic.html#futuresys when future system was killed ... there was made rush to get things back into the 370 hardware and software pipelines ... including vm370. Since I had continued to do 370 stuff all during the future system days (even making various criticism of future system stuff) ... I had a lot of unreleased 370 stuff. In any case, some amount of stuff from CSC/VM distribution was picked up for inclusion in VM370 Release 3. Part of that was CMS changes for additional shared segments (including work to make things "shareable" that hadn't previously been R/O protect) ... but not the page mapped filesystem. As a result, the additional CMS shared-segment stuff had to be mapped into the ipl-by-name facility and allowed to be invoked w/o going through the rest of the IPL simulation. This is what was called DCSS in VM370 Release 3. The posts containing the above email has some additional discussions about a very small subset of the paged-mapped filesystem support being released as DCSS http://www.garlic.com/~lynn/2006w.html#7 http://www.garlic.com/~lynn/2006w.html#8 http://www.garlic.com/~lynn/2006w.html#9 Also picked up from CSC/VM for VM370 Release 3 was the "autolog" command, which I had originally done for automated benchmarking.
--- 40+yrs virtualization experience (since Jan68), online at home since Mar1970
