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