|
> 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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.