On 26 Aug 2012 14:00:54 -0700, in bit.listserv.ibm-main zman wrote: >Good lord! Can you PLEASE try to post *vaguely* relevant material? This >makes you look like a troll.
Looking at this material (in the three postings from Lynn) which I consider highly relevant, I am wondering about the long term viability of mainframe style processing. The elimination of batch which seems to be feasible on non-mainframe architectures alone is a killer. The raw performance differences for computing are such that emulation of the z instruction set on Intel seems cost effective. The incentives to move to Java and other platform independent architectures by charging more for COBOL MIPS will just aggravate the trend. Once an organization has decided to go with SAP, is there any reason for it to try running SAP on z/OS? on z/Linux? I would be interested in any comparisons of the blade i-o architecture with that of the z series. I also note the bean counters refusal to sanction implementing FBA in MVS because of a 26 million dollar cost probably has resulted in an ongoing cost in the hundreds of millions of dollars. Clark Morris > >On Sun, Aug 26, 2012 at 3:46 PM, Anne & Lynn Wheeler <[email protected]>wrote: > >> [email protected] (Scott Ford) writes: >> > I saw the same exercise in a pharm. company trying to go from MVS, >> > multiple Lpars to unix. Several millions of $$$ and it was a >> > bust....some applications were difficult to convert >> >> in the 90s, one of the biggest efforts was by the financial industry >> (large concentration in manhatten) to move from overnight batch window >> to straight-through process ... using large numbers of "killer micros" >> ... where several billions were dumped down the drain. These efforts >> contributed to the "mainframe is dead" stories from the period. >> >> "real-time" transactions had been added to traditional batch ... but the >> actual processing was still being down in the overnight batch window. >> With globalization, there was combination of more work as well as >> decreasing window size ... that was putting enormous pressure on the >> paradigm. >> >> billions were spent on parallized implementation using large numbers >> "killer micros" implementing "straight-through" processing >> ... eliminated most of the work in the overnight batch window. They used >> some parallelization technology with roll-your-own implementations that >> looked good in the toy demos. However, they failed to so the >> speeds&feeds and when it came to production rollout ... the whole thing >> imploded horribly. The parallelization technology being used introduced >> an increase in overhead of 100 times (compared to cobol batch) >> ... totally swamping any anticipated throughput increase from large >> number of "killer micros" >> >> I had done some simple speeds&feeds and pointed out the issue before >> deployments but was ignored. I also got to work on improving performance >> of cobol batch that ran everynight batch window on more than 40 maxed >> out mainframes (40+ needed to handle workload, datacenter took pride in >> saying no mainframe was older than 18months). >> >> At least by the last half of the last decade, most of the major >> non-mainframe RDBMS vendors (including IBM) had made significant strides >> in non-mainframe RDBMS cluster-scaleup. I participated in demonstration >> of straight-through processing implementations that involved translating >> operations into fine-grain SQL operations that would could be easily >> parallelized by latest generation of non-mainframe RDBMS cluster >> implementations (more like factor of 3-5 times compared to cobol batch >> rather than 100 times). The financial industry standards organizations >> were interested but there were lots of comments there was still enormous >> resistance and risk aversion because of the lingering effects of the 90s >> disastrous failures. >> >> these large financial institutions continue to be major mainframe >> customer market. >> >> -- >> 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 >> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
