00000047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) writes:
> Until the mid-1990s, mainframes provided the only acceptable meansof
> handling the data processing requirements of a large business. These
> requirementswere then (and are often now) based on running large and
> complex programs,such as payroll and general ledger processing.
late 80s through early 90s there were lots of news stories about moving
off mainframes to "killer micros" ... and IBM has gone into the red. IBM
was being reorganized into the 13 "baby blues" in preparation for
breaking up the company ... when new CEO was brought in and reversed the
breakup.
late 70s & early 80s, I was involved in the original SQL/relational
implementation, System/R and the technology transfer to Endicott for
SQL/DS ("under the radar", while corporation was preoccupied with the
official next generation DBMS, "EAGLE"). When "EAGLE" finally imploded,
there was request about how fast could System/R be ported to MVS
... which was eventually released as DB2, originally for decision
support only.
Late 80s, was doing RS/6000 high availability HA/6000, but I quickly
change the name to HA/CMP because doing cluster scaleup,
technical/scientific with national labs and commercial with RDBMS
vendors. I'm also asked to write a section for the corporate strategic
continuous availability document. The section gets pulled when both
Rochester (AS/400) and POK (mainframe) complained they can't meet the
requirements.
Post about Jan1992 meeting in Ellison's conference room on 128-way
http://www.garlic.com/~lynn/95.html#13 one of the Oracle executives in
the room, said he was the major person in STL handling the tech transfer
to STL for DB2. Within a couple weeks of the Ellison meeting, cluster
scaleup is transferred, announced as supercomputer for
technical/scientific *ONLY*, and we are told we can't work on anything
with more than four processors. A few months later we leave. Part of the
issue was that mainframe DB2 were complaining that if I was allowed to
continue, it would be at least 5yrs ahead of what they were doing.
Later two of the oracle people in the Ellison meeting have left and are
at small client/server startup responsible for somehting called
"commerce server" and we are brought in as consultants because they want
to do payment transactions on the server, the startup had also invented
this technology they call "SLL", the result is now frequently called
"electronic commerce". For having done "electronic commerce", get
invited into lots of other financial industry activities.
In the mid/late 90s, lots of financial was overruning their (cobal batch
mainframe) overnight financial settlement window (globalization cutting
window size and increasing workload). Numerous were spending billions on
"straight through processing" (each transaction is settled as it
executes), leveraging huge parallelization with large number of "killer
micros". Turns out that they were using parallelization libraries that
introduced 100 times the overhead of cobol batch. They were warned
(including by me) about the problem, which they continued to ignore
... until large scale pilots went down spectacularly in flames (overhead
totally swamping anticipated increase in throughput with large numbers
of killer micros)
Decade later, I was involved in taking some technology to financial
industry groups, that had allowed high level business rules to be
specified ... that then were decomposed into fine-grain SQL statements
(easily parallelized). The implementation enormously reduced the
development and maintenance effort for large, complex business
operations ... and heavily leveraged vendor efforts in enormous
throughput for large clustered & parallel RDBMS (including IBMs). Was
able to demonstrate enormously complex business processing with many
times the throughput of any existing implementations. Initially it had
high level of acceptance, but then ran into brick wall. We were
eventually told that lots of the executives still bore the scars from
the enormous parallelization failures in the 90s and it would take all
of them retiring before it was tried again.
trivia: 2000, did some performance work on 450k statement cobol program
that did overnight batch settlement running every night on >40
max. configured mainframes (number of mainframes required to finish in
the overnight batch window).
--
virtualization experience starting Jan1968, online at home since Mar1970
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
