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] (Chris Mason) writes: > One of the presentations was someone from a big UK bank who defended > IBM having made the 155 and 165 available and relatively shortly > afterwards having announced the 158 and 168 - together with the > relatively expensive DAT box extension to the 155 and 165. I hope I'm > remembering the details about right. > > I heard about this only second-hand but I believe the argument was > that IBM was right to offer the enhanced performance of the 155 and > 165 as soon as it could in spite of the fact that it knew that the > virtual storage models were well advanced in development. I guess > there was a shadow of the "it's illegal to preannounce" principle > hanging over this. re: http://www.garlic.com/~lynn/2007n.html#31 IBM obsoleting mainframe hardware http://www.garlic.com/~lynn/2007n.html#34 IBM obsoleting mainframe hardware 370/165 ... announce jun70 http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3165.html 370/168 ... announce aug72 http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3168.html for virtual memory ... hacking virtual memory support into MVT (for VS2/SVS) was needed in addition to the virtual memory hardware retrofitted to 165s (there were significant software as well as hardware schedules). this is similar to previous comments about *crash* program to try and get out 370-xa (after FS project was killed) and POK in 1976, convincing the corporation to shutdown vm370 product and transfer all the developers to POK as part of being able to make mvs/xa (software) schedule (although Endicott was eventually able to save part of the vm370 product mission). i've mentioned before about (370 virtual memory) prototype work that went on in pok, using 360/67s and hacking "single address space" virtual memory into the side of MVT ... as well as cobbling in cp67's (ccw translation) CCWTRAN into MVT ... i.e. cp67 had started out having to build "shadow" channel programs with real addresses ... for the virtual machine's channel programs; all the (MVT) channel programs passed via EXCP ... would be equivalent "virtual address" channel programs ... requiring similar translation (and misc. other things like page locking/pinning) recent posts about using CP67's CCWTRANS as part of turning MVT into os2/svs 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 The other part ... was that there was a lot of work to retrofit virtual memory to 165 ... so much so that they ran into schedule problems. In order to buy back six months in the 165 virtual memory schedule, there was an escalation dropping several features from the original 370 virtual memory architecture. Once the 165 engineers had won that battle, then all the other processors (that had already completed their virtual memory implementations) ... had to go back and remove the dropped features. recent posts mentioning 165-ii schedule issues and impact on dropping features from original 370 virtual memory architecture http://www.garlic.com/~lynn/2007f.html#7 IBM S/360 series operating systems history http://www.garlic.com/~lynn/2007f.html#16 more shared segment archeology http://www.garlic.com/~lynn/2007j.html#43 z/VM usability http://www.garlic.com/~lynn/2007k.html#28 IBM 360 Model 20 Questions ---------------------------------------------------------------------- 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
