RE: BPCS History

[Jim Damato <jdamato@xxxxxxxxxxxxxxxxx>]

Cool post, Joe.  Kind of like the condensed version of Soul of a New
Machine.  A few stand-out points, for me:

>Unix experts were brought in, who insisted that SQL was
>more than a match for DB2...
>...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).

Converting RPG file operations opcode by opcode to SQL, what a messy
concept.  Like replacing a canoe with a rowboat, but keeping your paddle.
This is what Lawson ended up doing -- emulating AS/400 ISAM operations on
top of an SQL database.  It's a great way to horrify DBA's and SQL
developers.


>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.

It always amazes me how Work Management is taken for granted on Unix and
Windows servers.  So many sys admins and programmers give me a "why would
you need to do that?" -- until they're in a situation where more than five
processes are spawned simultaneously.  I've seen about a dozen half-a$$ed,
incredibly complex, hardcoded messes designed to throttle processes through
daemons, text-file based tracking mechanisms, etc., for specific software
products.  Lawson's is probably the best I've seen -- a passable OS/400 work
management clone.  Still the benefit of a consistent configurable queuing,
prioritizing batch interface managed by the OPERATING SYSTEM doesn't impress
some folks.


-Jim

James P. Damato
Manager - Technical Administration
Dollar General Corporation
<mailto:jdamato@xxxxxxxxxxxxxxxxx>