Alan Altmark wrote:
Well, it's been nigh on 40 years that CMS has been around. Seems like a committment to me. CMS is here to stay. If all the people with z/OS get z/VM and [re]discover CMS, who knows what might happen? "Never say die!"
re: http://www.garlic.com/~lynn/2007j.html#41 z/VM usability well, cms (as in cambridge monitor system) started on cp40 (cambridge had gotten a 360/40 and did the hardware modifications to implement virtual memory ... pending getting 360/67) ... cambridge then got 360/67 and morphed cp40 into cp67 ... so it has been 40yrs (in part, CMS work could even start on real 360/40 before cp40 was operational) from Melinda's history http://www.princeton.edu/~melinda/ By September of 1965, file system commands and macros already looked much like those we are familiar with today: ``RDBUF'', ``WRBUF'', ``FINIS'', ``STATE'', etc ... snip ... cambridge installed cp67 out at lincoln labs in 1967 and then last week in jan68 came out to install cp67 at the univ where i was undergraduate. Note, that in jan68, the cp67 people were still apprehensive about CMS filesystem ... with cp67 source, assemble, and build still being done on os/360 (keeping cp67 kernel build TXT files in card tray and modify/assemble routine, punch new TXT file, update that file in the card tray and rebuild kernel by doing IPL of real cards). in the morph of cp67 to vm370 ... they changed the cms name to conversational monitor system. major change in cms from cp67 to vm370 was a little re-arranging of cms kernel in anticipation of 370 (r/o) segment protection. However, in doing the virtual memory hardware retrofit to 370/165 ... they ran into problem with schedule slipping. In order to regain six months in the schedule for 370/165 virtual memory, they dropped r/o segment protect and some number of other features from the original 370 virtual memory architecture (and to have compatibility across the 370 product line ... the same features had to also be removed from other 370 models that already had implemented the full 370 virtual memory architecture). With 370 hardware r/o segment protect dropped ... vm370 had to revert to the page protect hack used by cp67 that involved fiddling the 360 storage protect keys. Then during the "future system" period ... much of the corporation was distracted and a lot of 370 product activity fell by the way side. Misc. past posts about future system: http://www.garlic.com/~lynn/subtopic.html#futuresys I had made some unflattering comments about practicallity of future system stuff and continued to do both cp67 and cms enhancements ... and then ported them from cp67 to vm370 ... some old email http://www.garlic.com/~lynn/2006v.html#email731212 http://www.garlic.com/~lynn/2006w.html#email750102 http://www.garlic.com/~lynn/2006w.html#email750430 after FS was canceled, there was rush to get stuff back into 370 product pipeline. Part of this was reason that small subset of the "virtual memory management" enhancements ... a lot of shared segment stuff http://www.garlic.com/~lynn/subtopic.html#adcon that had been integrated with the paged mapped filesystem stuff http://www.garlic.com/~lynn/subtopic.html#mmap was released as DCSS in vm370 release 3. Canceling FS contributed to enabling me to also release the resource manager (that included a lot of changes that were in cp67 that i had done ... which were dropped in the morph from cp67 to vm370) http://www.garlic.com/~lynn/subtopic.html#fairshare http://www.garlic.com/~lynn/subtopic.html#wsclock It was also in the aftermath of killing FS that POK convinced the corporation to kill the vm370 product, shutdown the vm370 product group and move all the people to POK to help accelerate the mvs/xa development schedule (again attempting to make up lost time in 370 product pipeline resulting from the FS distraction). Eventually Endicott was able to salvage the vm370 product mission.
