The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main as well.
[email protected] (Scott T. Harder) writes: > I rather think that "they" (client/server model... "we're getting rid > of the mainframe") tried that in the 90's. there were lots of claims that SAA was countermeasure to client/server in the late 80s and early 90s. there was huge amount of leakage of applications out of the datacenter which significantly drove the market for non-datacenter computing but the whole non-datacenter disk drive market (enormous appetite for non-datacenter disk storage for all the applications leaving the datacenter and new generation of applications). one of the senior people from the disk division got a talk scheduled at the annual communication world-wide conference ... and started out the talk by stating that the head of the communication division was going to be the demise of the disk division. and then went on to explain that the communication division was straggling the data transfer thruput into & out of the datacenter ... which contributed significantly to the huge spike for disk storage outside the datacenter. that wasn't so much getting rid of the mainframe ... but severely constrained datacenter growth. my wife had run into similar battles with the communication group which she was con'ed into going to POK to be in charge of loosely-coupled architecture. She had come up with peer-coupled shareddata architecture, except for IMS hot-standby, which saw very little uptake until sysplex. misc. past posts http://www.garlic.com/submain.html#shareddata She reached a (temporary) truce with the communication group where she could use anything she wanted to withing the walls of the datacenter. the issue was that the communication had established large install base of products related to terminal emulation ... from early days of introduction of PCs. as PC became more powerful (and workstations became more plentiful) there was growing shift for more powerful data transport technologies (both thruput and function). this set the stage for things like SAA attempting to preserve the terminal emulation install base. misc. past posts mentioning terminal emulation period http://www.garlic.com/~lynn/subnetwork.html#emulation as outgrowth of HSDT (high-speed data transport) project ... misc. past posts http://www.garlic.com/~lynn/subnetwork.html#hsdt recent reference in this mailing list http://www.garlic.com/~lynn/2009g.html#72 we had come up with 3-tier architecture and was out pitching to customer executives ... and taking some amount of heat from the SAA crowd ... misc. past posts http://www.garlic.com/~lynn/subnetwork.html#3tier in the 90s, there was a growth in clusters as mainframe replacement ... old post mentioning early Jan 92 meeting on cluster scaleup http://www.garlic.com/~lynn/95.html#13 not long afterwards, the effort was transferred and we were told we couldn't work on anything with more than four processors ... some past posts http://www.garlic.com/~lynn/subtopic.html#hacmp and old email (cluster in a rack): http://www.garlic.com/~lynn/lhwemail.html#medusa which was then announced as a numerical intensive product within a couple weeks ... a couple news announcements in Feb 92 http://www.garlic.com/~lynn/2001n.html#6000clusters1 in this post http://www.garlic.com/~lynn/2001n.html#83 and http://www.garlic.com/~lynn/2001n.html#6000clusters2 in this post http://www.garlic.com/~lynn/2001n.html#70 in the 90s, there were billions spent on (failed) redoing some number of mainframe production work on parallel, "killer micros". There were a large set of "online" mainframe applications that appeared in 70s & 80s ... which were somewhat a outgrowth of earlier batch operations. However, the business process still was dependent on overnight batch operations. In the 90s, with increasing business and globalization, there was huge stress being placed on these "overnight batch windows". Numerous efforts were attempted using "object-oriented" technologies to re-engineer these mainframe batch workloads; parallelizing and distributing workloads across large numbers of "killer micros". This was frequently "straight through precessing" ... each online operation was run to completion ... instead of delaying part of the processing to the "overnight batch window". The problem was that the parallel distribution object-oriented technologies introduced a factor of 100 times (two orders of magnitude) increase in processing overhead ... totally swamping any anticipated throughput benefits of large number of killer micros. misc. recent posts mentioning "killer micros", "overnight batch windows" and "straight through processing": http://www.garlic.com/~lynn/2009.html#87 Cleaning Up Spaghetti Code vs. Getting Rid of It http://www.garlic.com/~lynn/2009c.html#43 Business process re-engineering http://www.garlic.com/~lynn/2009d.html#14 Legacy clearing threat to OTC derivatives warns State Street http://www.garlic.com/~lynn/2009f.html#55 Cobol hits 50 and keeps counting -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 ---------------------------------------------------------------------- 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
