Re: BPCS History

Thanks Joe, I've always wondered why the CPR stuff and the OEAMNU stuff
never got finished, it seemed such a great idea!
Of course I knew about the Unix debacle and was even asked to project manage
in Bangalore but said no....
I was at SSA from 1988 to 2000, and it was great in the early years, but the
tragedy is still playing out! Latest is that SSA Europe have decided to
'outsource' professional services!
And the SQL provides me with more performance tuning business creating
indexes.
What will happen to BPCS? There are still plenty of people using it, some
still on V4.05CD (pre-SQL). Very sad though....

cheers,

Clare


Clare Holtham
Director, Small Blue Ltd - Archiving for BPCS
Web: www.smallblue.co.uk
IBM Certified AS/400 Systems Professional
E-Mail: Clare.Holtham@xxxxxxxxxxxxxx
Mobile: +44 (0)7960 665958
----- Original Message -----
From: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx>
Sent: Monday, September 22, 2003 10:13 PM
Subject: BPCS History


> > From: shannonjano@xxxxxxxxxxxxxxx
> >
> > Can you expand on your comments a bit about BPCS?  I used it many,
> many,
> > MANY years ago and liked it back then (somewhere around 1989/1990).
> >
> > Were you working there when they chose the SQL course?
> >
> > I guess what I'm asking for is war stories and gossip. :-)
>
> I'll post one semi-autobiographical account of the demise of The SSA
> That Covey Built.  This is based on memory and some conjecture, so
> accuracy is in the eye of the beholder.
>
> During my last years at SSA, we were in the midst of the client/server
> revolution and at that time, it was all thick client.  We were also
> trying to figure out configurable processing, which meant the ability
> for end users to customize their workflows (for things like order
> entry).
>
> We had an incredible architecture in place, that we called CPR (for
> Configurable Processing, but I coined the term with no small amount of
> amusement at the irony of the acronym).  This architecture was going to
> revolutionize the industry.  Small, independent modules could be called
> anywhere in the job flow.  Each session would keep track of the current
> session information, and each module would query the session for needed
> information.  If it didn't find what it needed, it would prompt the
> user.  The panel it used could be different for different users,
> allowing either fast path entry or more detailed transactions.
>
> All database interactions were encapsulated by server programs.  The
> servers all shared a common interface and could be invoked by any
> program.  Related files (header/detail) were processed by the same
> server, and servers could in turn invoke other servers to resolve
> foreign keys as necessary.
>
> What a concept!  And all in RPG III, no service programs, none of that.
> We made use of data queues and programs that didn't turn off LR.
> Sessions and even individual transactions could be restarted in case of
> errors, all that good stuff. And this cleared the way to interaction
> with thick clients, which could all call the same servers (can you say
> "web service"?).
>
> And then it happened.  In the early 90's management turnovers started
> happening.  Roger Covey (the architect of the software and founder of
> the company) was spending extended time in China, both for personal
> pursuits (he was an Asian history scholar and spoke Mandarin, if not
> other dialects) and in an attempt to exploit the fledgling Chinese
> manufacturing industry.  A former marketing Veep from IBM was brought in
> to run the show, and rather than the late-night technical arguments
> (often in the local tavern) between the technical managers and the
> President that had directed the architecture of the package, instead
> technical decisions began to be made in boardroom meetings by
> non-technical people.  Decisions were soon based not on sound technical
> merits, but on the latest buzzword of the day.  "Platform independence"
> started to rear its ugly head, and thus began the ill-fated move towards
> Unix and SQL.
>
> Unix experts were brought in, who insisted that SQL was more than a
> match for DB2, and that OS/400 wasn't really that complex an operating
> system; they could emulate both inside of a year.  I remember finding
> this amusing, especially the one code cowboy who insisted that he could
> write an AWK script to convert RPG to C in a single pass.
>
> Thus began the road to perdition.  A few of us declaimed the Emperor's
> nakedness, but in general we were shouted down by visions of
> marketshare, not to mention the newly found motherlode of cheap labor to
> be had in places like Bangalore.
>
> Anyway, to cut the story short, projections of writing the emulation
> were wildly optimistic, to say the least.  Having no concept of things
> like program to program calls, it turned out that Unix wasn't quite
> ready to emulate OS/400.
>
> An example: Program calls with parameters were emulated by writing the
> parameters to a file, spawning the called program and waiting.  The
> spawned program would then read in the parameters, do its thing, and
> write the parms back to the file.  The calling program would then wake
> up and read those parameters in.  As you might guess, this had some
> negative impact on performance.
>
> Another example: in an effort to maximize the ability to
> programmatically convert code from RPG to SQL/C, the C programmers
> simply chose the easiest way to do things.  Nobody who knew both systems
> was in charge, and the SQL experts weren't exactly adept at business
> programming.  Thus, a CHAIN became a SELECT using a cursor (because you
> never knew if someone was then going to do a READP).
>
> Then, in order to try and catch up with the schedule, the first option
> was to farm as much as possible to India.  The results, especially with
> the state of the Internet back then and the hit or miss ability to send
> large files, were less than stellar.  So, the client/server project
> began to be cannibalized.  I raised more of a stink, and that was the
> beginning of the end of my tenure at the company.
>
> Interestingly enough, I did have one last major part in this IT tragedy.
> Near the end, as the product was about to be delivered to the first beta
> sites, somebody noticed something.  Nobody had bothered to convert CL
> programs.  In fact, nobody had bothered to even design the basic
> features of CL programs, such as overrides, or message queues, or
> printer files, or even the concept of a batch job.  Over the course of
> three weeks I became intimately familiar with HP-UX as I basically wrote
> an OS/400 emulator, and the product finally limped (and that's putting
> it kindly) out the door.
>
> As you can see, by this time pretty much all the resources of the
> company had been bet on this new technological direction, all processes
> had been transformed from the traditional development life cycle to a
> bastardized combination of rapid application development and outsourced
> programming with no real design lead.
>
> And when the thing was released, it was slow, lumbering, error-ridden,
> and ugly (remember, it was STILL a text-based interface - the closest it
> ever came to anything GUI was a nasty screen scraper front end that
> didn't even function properly with character-based Unix terminals).
> Nobody bought it, and rather than cut their losses, they continued to
> pour money into it.  Any true innovation (such as the modular
> client/server architecture) went by the wayside.  Some left, some were
> fired, some just burnt out.
>
> And thus ends the tale, the sad tale, of The SSA That Covey Built.
>
> Joe
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>