Re: BPCS-L Digest V2 #130 -- BPCS-L

 Re the AS/SET discussion, I spent 1995 digging through AS/SET generated RPG
to figure out what the dickens it was doing.  I can pass on the following
comments:

  -  SSA gave us the task of creating an online transaction processing
interface between BPCS and the Incode shop floor control system used by
SmithKline Beecham and Ciba-Geigy.  It was to be completely in AS/SET and be
able to run on the AS/400 or Unix, and we made calls in it to BPCS programs
like CIM600 and excerpted logic from other BPCS programs like INV510.  I
isolated out AS/400 dependent calls in the new AS/SET code to CL or small RPG
programs accessing such things as data areas to small programs which would be
replaced with Unix command equivalents.

The AS/400 code was shipped and tested extensively by SKB London and found to
be flawless.  The tests were done with a green screen test utility we provided
that threw transactions into an incoming file just as the Incode OS/2 code
would do with an SQL INSERT statement through DRDA later, but Incode was not
quite done yet at the time.  SSA, which did not have the resources to do this
interface and was under pressure from their large customers for an online
update from the shop floor for more than INV500 transactions (CIM600), having
seen us create and ship the program, then started making noises about BPCS 6.0
having the same kind of interface already built in.  BPCS 6.x didn't ship for
two more years and ended up not having this interface, but the vaporware
whispering campaign froze their customers from buying a product that had been
spec'ed by SSA themselves.  They were paranoid about anybody getting too
comfortable with BPCS 4.x and not wanting to ditch it to go to AS/SET and 6.x.

Even though the shop floor transaction processing interface was in AS/SET, it
had BPCS 4.x version specific logic in it.  Anything that accessed BPCS was by
definition version specific, and we designed the interface to handle calling
to different versions, both newer and older.  Ciba-Geigy still had 3.x running
in England, and 5.x was already out.  So we were prepared to handle 5.x and
6.x, but SSA said the new object orientation of 6.x would make such an
interface superfluous, just eight months after requesting it as a means to
meet the needs of their customers.  We had even bought an HP9000 at SSA's
request to make the product work under HP-UX as well, but SSA knifed us in the
back and so the product went on a shelf, just as SOM did at SSA, ironically, a
year before as similar screwups occurred.

  - The classic tradeoffs of CASE tool productivity versus inflexibilty and
unoptimized code are usually a judgement call, except when your line of
business software is delivered in CASE.  Given that, my prime objective was
not only to deliver an excellent product, but one done without after the fact
tweaking of generated code.  I accomplished that, but the gyrations I went
through to give AS/SET enough clues to generate correct code were mind
boggling.  Once you figured out that certain approaches threw it off and
others worked, the ones that worked were used even if we didn't understand why
perfectly valid AS/SET code was not handled properly.  Obviously, it was bugs
in the code generator so you ended up working around them, while also
reporting them of course, though you would never see a fix in the course of a
year.

  - I had rookies available, benchwarmers, who just didn't have the mental
capacity to do subfile programming no matter how good of a shell you gave
them, no matter how carefully you walked through doing a program with them, no
matter how much help you gave them.  It was just over their heads, which is
pretty scary.  Yet they were able to create subfile programs in AS/SET without
a problem.  AS/SET definitely gave more capability to less experienced
programmers, and gave them a chance to be productive.  Unfortunately, they
also tended to walk through the debugger all day unless required to go their
project leader with any problem they couldn't solve in an hour.  Still, with
AS/SET and careful supervision, they were productive.  But a good RPG
programmer is a lot cheaper.

 Regards,
 Ralph
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---