[email protected] (Bill Wilkie) writes: > But the biggest BOONDOGGLE of all times, was what management spent a > few million on and that was Four Quadrant Leadership. If discussed > something with another person and YOU made the change you were > operating from Quadrant 1. If you discussed it with another persons > and THEY did it you were operating from Quadrant 2. No one ever > figured out whay it was important but everyone in the company had to > take the course. We spent millions and the manager who bought it was > called a VISIONARY. I suspect or should I say HOPE he is on the > unemployment line with the rest of the visionaries.
mid-80s, top IBM executives were predicting that corporate revenue would double mostly based on mainframe business ... and there was massive internal bldg program to double mainframe manufacturing capacity. however, a couple years later, a senior disk engineer got a talk scheduled at the internal, world-wide communication group conference supposedly on 3174 performance, but opened the talk with statement that the communication group was going to be responsible for the demise of the disk division. The issue was that the communication group had stanglehold on datacenter with their corporate strategic responsibility for everything that crossed the datacenter walls and were fiercely fighting distributed computing and client/server trying to preserve their dumb terminal paradigm and install base. The disk division was seeing data fleeing the datacenter to more distributed computing friendly platforms with drop in disk sales. They had come up with several solutions which were constantly vetoed by the communication group. The communication group stranglehold on the datacenter not only was affecting disk sales but everything mainframe and a few short years later the company goes into the red. By the mid-90s, most of the easier applications had fled mainframes (driving IBM into the red) and the major remaining customer was the financial industry (accounting for significant percentage of all new mainframe sales). However, the financial industry was facing significant bottleneck with decades old legacy cobol financial software that did settlement in the overnight batch window ... and globalization (shortening the window) and business increases (increasing workload) was putting extreme strain on the overnight batch window. Late 90s, there was a period where the financial industry spends billions of dollars on new software to support parallized "straight through processing" (real-time settlement with every transaction), planning on using large numbers of killer micros. However there were using some industry standard parallelization libraries ... and they continued down the path even when repeatedly told (including by me) the libraries introduced factor of 100 times overhead (compared to mainframe batch cobol). It wasn't until they actually had some major large pilots go down in flames that they pulled back (100 times overhead totally swamped anticipated throughput increases from large numbers of parallelized killer micros). A decade later, I was involved in effort that approached it from a different standpoint. It supported high level business rules that generated fine-grain, parallelizable SQL statements, and rather than directly implementing parallelization ... it relied on the enormous work that all the RDBMS vendors (including IBM) put into scalable cluster parallelized throughput. Prototype pilots were implemented for different financial sectors that easily supported several times their current peak workloads on non-mainframe cluster RDBMS platforms. This was presented to several financial industry groups and initially had high acceptance ... but then hit brick wall. They eventually said that the top executives still bore significant scars from the failed efforts in the late 90s and it would be a very long time before it would be tried again. Note that SQL/RDBMS features are common across mainframe and non-mainframe platforms ... all platforms use industry standard fixed-block disks, non-mainframes getting slightly better throughput than mainframe doing CKD simulation on same industry standard disks (real CKD disks haven't been made for decades). Native fibre-channel having significantly higher native throughput than mainframe FICON protocol running over the same fibre-channel. The most recent published mainframe peak I/O throughput that I've found is z196 getting 2M IOPS using 104 FICON. About the same time there was fibre channel announced for E5-2600V1 blade claiming over million IOPS (for single fibre-channel, two such fibre-channel having higher native throughput than 104 FICON running over 104 fibre-channel). max configured z196->z14 went from 80 @625MIPS for 50BIPS to 170 @882MIPS for 150BIPS (three times aggregate processing with more than double the number of slightly faster processors). In the same time frame, two chip e5-2600V1 blade at 530BIPS went to two chip e5-2600v5 at about 4-5 times the aggregate BIPS rate (based on benchmark iterations ratio to iterations run on 370/158 assumed to be 1MIPS processor). trivia: in 1988 I was asked to help LLNL (LL national lab) help standardize some serial stuff they were working with, which quickly becomes fibre-channel standard ... some past FICON & fibre-channel posts http://www.garlic.com/~lynn/submisc.html#ficon other triva: in 1980, I was asked to do channel-extender support for STL (now SVL) that was moving 300 people from IMS group to offsite bldg. This included doing lot of the channel protocol stuff at the remote site (significantly reducing the significant channel protocol latency). This is included in the 1988 fibre-channel stuff but not leveraged in FICON. Something similar shows up somewhat in zHPF/TCH (30yrs later) ... but only claims 30% throughput improvement over standard FICON. -- 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
