The following message is a courtesy copy of an article that has been posted to alt.folklore.computers as well.
re: http://www.garlic.com/~lynn/2007s.html#33 Age of IBM VM http://www.garlic.com/~lynn/2007s.html#36 Oracle Introduces Oracle VM As It Leaps Into Virtualization one could claim that the relationship of cp67 to vm370 is somewhat like the relationship of HASP to JES2. misc past posts mentioning HASP, JES2, and/or JES2/HASP networking support http://www.garlic.com/~lynn/subtopic.html#hasp other cp67 heritage ... in the transition from MVT to os/vs2 (i.e. os/360 with virtual memory support) ... basically MVT was laid out in single virtual address space ... thus the reference to OS/VS2 SVS (single virtual storage) to distinquish from later OS/VS2 release MVS (multiple virtual storage). One might claim that there was little difference between OS/VS2 SVS and MVT with VM handshaking laid out in 16mbyte virtual address space. The biggest difference was needed to have channel program translation built into MVT. The initial prototypes of OS/VS2 SVS was built with minimal virtual address space support and a copy of CP67 CCWTRANS (and a couple other CP67 routines associated with channel program translation) hacked into the side. misc. recent posts discussing channel program translation and specifically getting os/vs2 to support it http://www.garlic.com/~lynn/2007e.html#19 Cycles per ASM instruction http://www.garlic.com/~lynn/2007e.html#27 IBM S/360 series operating systems history http://www.garlic.com/~lynn/2007e.html#46 FBA rant http://www.garlic.com/~lynn/2007f.html#0 FBA rant http://www.garlic.com/~lynn/2007f.html#6 IBM S/360 series operating systems history http://www.garlic.com/~lynn/2007f.html#33 Historical curiosity question http://www.garlic.com/~lynn/2007f.html#34 Historical curiosity question http://www.garlic.com/~lynn/2007k.html#26 user level TCP implementation http://www.garlic.com/~lynn/2007n.html#35 IBM obsoleting mainframe hardware http://www.garlic.com/~lynn/2007o.html#37 Each CPU usage http://www.garlic.com/~lynn/2007o.html#41 Virtual Storage implementation http://www.garlic.com/~lynn/2007p.html#69 GETMAIN/FREEMAIN and virtual storage backing up http://www.garlic.com/~lynn/2007p.html#70 GETMAIN/FREEMAIN and virtual storage backing up http://www.garlic.com/~lynn/2007p.html#72 A question for the Wheelers - Diagnose instruction http://www.garlic.com/~lynn/2007q.html#8 GETMAIN/FREEMAIN and virtual storage backing up http://www.garlic.com/~lynn/2007r.html#56 CSA 'above the bar' http://www.garlic.com/~lynn/2007s.html#2 Real storage usage - a quick question http://www.garlic.com/~lynn/2007s.html#9 Poster of computer hardware events? there was other technology from the science center http://www.garlic.com/~lynn/subtopic.html#545tech used in lots of transition to operating in virtual memory environment for 370. the science center had a number of efforts going on in the area of system and performance monitoring, modeling, and simulation (some of it being the runup to capacity planning). one of the projects involved tracing instruction and data storage references and then doing semi-automated program reorganization to optimize for operation in virtual memory environment. This was used for several yrs internally before being turned into product and released to customers as "VS/REPACK" (two moments before my vm370 resource manager was first released). An early version of the technology was used to help in the morph of apl\360 to cms\apl (originally on cp67/cms) ... which required completely redoing the apl storage allocation and garbage collection implementation for operation in virtual memory environment. vs/repack was also used by a number of product groups ... not only for helping with transition from real storage to virtual memory environment ... but also for things like application "hot spot" identification (i.e. where program is spending a lot of its time). For instance it was used in STL by the IMS development group for extensive studies of IMS operation and performance. misc. recent posts mentioning VS/REPACK http://www.garlic.com/~lynn/2007g.html#31 Wylbur and Paging http://www.garlic.com/~lynn/2007m.html#55 Capacity and Relational Database http://www.garlic.com/~lynn/2007o.html#53 Virtual Storage implementation http://www.garlic.com/~lynn/2007o.html#57 ACP/TPF another tool was an system performance analytical model implemented in APL which was eventually made available as sales and marketing support tool on (internal cms-based timesharing service) HONE http://www.garlic.com/~lynn/subtopic.html#hone as the "performance predictor". branch people could input customer configuration and workload details and ask "what-if" questions about what would happen if there were configuration and/or workload changes. misc. past posts mentioning "performance predictor" http://www.garlic.com/~lynn/2001i.html#46 Withdrawal Announcement 901-218 - No More 'small machines' http://www.garlic.com/~lynn/2002b.html#64 ... the need for a Museum of Computer Software http://www.garlic.com/~lynn/2002c.html#45 cp/67 addenda (cross-post warning) http://www.garlic.com/~lynn/2002q.html#28 Origin of XAUTOLOG (x-post) http://www.garlic.com/~lynn/2003g.html#15 Disk capacity and backup solutions http://www.garlic.com/~lynn/2003p.html#29 Sun researchers: Computers do bad math ;) http://www.garlic.com/~lynn/2004g.html#42 command line switches [Re: [REALLY OT!] Overuse of symbolic constants] http://www.garlic.com/~lynn/2004k.html#31 capacity planning: art, science or magic? http://www.garlic.com/~lynn/2004o.html#10 Multi-processor timing issue http://www.garlic.com/~lynn/2005d.html#1 Self restarting property of RTOS-How it works? http://www.garlic.com/~lynn/2005d.html#6 [Lit.] Buffer overruns http://www.garlic.com/~lynn/2005d.html#33 Thou shalt have no other gods before the ANSI C standard http://www.garlic.com/~lynn/2005d.html#48 Secure design http://www.garlic.com/~lynn/2005h.html#1 Single System Image questions http://www.garlic.com/~lynn/2005h.html#15 Exceptions at basic block boundaries http://www.garlic.com/~lynn/2005j.html#12 Performance and Capacity Planning http://www.garlic.com/~lynn/2005k.html#17 More on garbage collection http://www.garlic.com/~lynn/2005o.html#30 auto reIPL http://www.garlic.com/~lynn/2005o.html#34 Not enough parallelism in programming http://www.garlic.com/~lynn/2006b.html#15 {SPAM?} Re: Expanded Storage http://www.garlic.com/~lynn/2006b.html#17 {SPAM?} Re: Expanded Storage http://www.garlic.com/~lynn/2006f.html#22 A very basic question http://www.garlic.com/~lynn/2006f.html#30 A very basic question http://www.garlic.com/~lynn/2006g.html#34 The Pankian Metaphor http://www.garlic.com/~lynn/2006h.html#25 The Pankian Metaphor http://www.garlic.com/~lynn/2006l.html#3 virtual memory http://www.garlic.com/~lynn/2006o.html#23 Strobe equivalents http://www.garlic.com/~lynn/2006o.html#25 CPU usage for paging http://www.garlic.com/~lynn/2006s.html#24 Curiousity: CPU % for COBOL program http://www.garlic.com/~lynn/2006t.html#28 Why these original FORTRAN quirks? http://www.garlic.com/~lynn/2007k.html#65 Non-Standard Mainframe Language? http://www.garlic.com/~lynn/2007r.html#68 High order bit in 31/24 bit address
