[email protected] (Phil Smith) writes: > VM/XA MA begat VM/XA SF begat VM/XA SP, which eventually moved to > Endicott, and became VM/ESA and then z/VM. The core of VM/XA was > actually much better than VM/SP; as a developer I found it much easier > to work with.
re: http://www.garlic.com/~lynn/2012g.html#17 Co-existance of z/OS and z/VM on same DASD farm http://www.garlic.com/~lynn/2012g.html#19 Co-existance of z/OS and z/VM on same DASD farm http://www.garlic.com/~lynn/2012g.html#24 Co-existance of z/OS and z/VM on same DASD farm old email about vm/370 running in XA mode: http://www.garlic.com/~lynn/2011c.html#email860122 http://www.garlic.com/~lynn/2011c.html#email860123 http://www.garlic.com/~lynn/2011e.html#email870508 the early issue were claims that the resources to bring "migration aid" up to vm370 product level was several orders larger than the resources needed to fix any perceived deficiencies in vm370 (compared to "migration aid"). for little x-over with this thread: http://www.garlic.com/~lynn/2012g.html#29 24/7/365 appropriateness was Re: IBMLink outages in 2012 http://www.garlic.com/~lynn/2012g.html#30 24/7/365 appropriateness was Re: IBMLink outages in 2012 post from couple years ago about z/VM announcing cluster support: http://www.garlic.com/~lynn/2009p.html#43 From The Annals of Release No Software Before Its Time US HONE system had done vm370 cluster (loosely-coupled) & single-system-image support in the late 70s (large number of multiprocessors sharing disk pool) ... US HONE datacenters had been consolidated in Palo Alto in mid-70s (building next door to where FACEBOOK later first moved into) and provided online sales&marketing support (HONE clones sprouted all over the world for world-wide sales&marketing support). In the early 80s, the datacenter was replicated in Dallas, and fall-over/load-balancing was extended across the two geographically separated datacenters. misc. poast posts mentioning HONE http://www.garlic.com/~lynn/subtopic.html#hone Prior to US HONE cluster support, vm370 commerical online service bureaus had done their own cluster support including non-disruptive migration of active running users between systems in the complex (not just logon load-balancing and fall-over). This allowed a system to be taken/varied offline for maintenance w/o impacting any users running on the system. misc. past posts mentioning commercial online service http://www.garlic.com/~lynn/submain.html#timeshare In the 80s, IBM research had done vm/4341 cluster support with 3088/trotter ... but when they went to release, they were told that they had to convert from their own home grown protocol to SNA/VTAM ... cluster operations that had taken small fraction of a second started taking half a minute or more. all of that would be disappearing in transition from vm370 base to vmtool/migration-aid base. with regard to loosely-coupled and SNA/VTAM battles ... my wife had earlier run into the problem when she had been con'ed into going to POK to be in charge of loosely-coupled architecture. She created peer-coupled shared data architecture while there ... but it saw very little uptake (except for IMS hot-standby) until SYSPLEX ... some past posts http://www.garlic.com/~lynn/submain.html#shareddata combination of little uptake and constant wars with the communication group over demands that she use SNA/VTAM for loosely-coupled operation contributed to her not remaining long in the position (there would be periodic temporary truces where it was allowed she could use anything she wanted within the datacenter ... but the communication group "owned" everything that crossed the datacenter walls). also note in the late 80s, a senior disk engineer had gotten a talked scheduled at the internal, worldwide, annual communication group conference and opened with the statement that the communication group was going to be responsible for the demise of the disk division. the issue that the communication group was protecting their terminal emulation install base ... and the disk division was starting to see drop of sales as data was fleeing the datacenter to more distributed computing friendly platforms. The disk division had come up with a number of solutions for the problem ... but (again) the communication group had strategic ownership for everything that cross the datacenter walls (and would veto the solutions). misc. past posts mentioning terminal emulation paradigm http://www.garlic.com/~lynn/subnetwork.html#emulation this whole situation contributed to the significant dropoff of mainframe use and the company going into the red in early 90s. Reference to a Gerstner's resurrection of IBM ... as well as pointer to review of Gerstner's book "who says elephants can't dance" (in IBM employee forum): http://www.garlic.com/~lynn/2012f.html#84 -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
