RE: BPCS History

> From: rob@xxxxxxxxx
>
> There were a host of other problems.  Like their attempts at EDI.
> Everybody and their brother had an EDI package.  What the market
needed
> was the ability to interface that data from EDI into ERP.  What needed
to
> be done was reopening batch interfaces into order entry, etc.
Granted,
> due to the joke of EDI every interface would probably need to be
> customized, but a starting point was needed.  They chose to come out
with
> yet another EDI package.

Actually, SSA bought another company's very successful EDI add-on.  We
made a ton of money on that.  EDI was just basically a license to steal
for many years, and the customer just kept paying.


> Another example was numerous attempts to develop their own development
> environment for client server computing.  Never did get off the
ground,
> was cost prohibitive, and even if you used their Client/Server model
you
> still had to have them do most, if not all, of the customization
because
> they wouldn't release that part of the tool.

The client/server architecture is still at the core of the package
today.  Remember that you can use clients and servers on the same
machine; BPCS got that part correct.  Where it failed miserably was the
thick client, which as we know now is in most cases a bad architecture.
The biggest problem was that we bought into the OS/2 hype and basically
got wiped out when IBM abandoned OS/2.

Had there been such a thing as a browser interface back then, we would
have kicked some serious butt.  Instead, we had to keep trying to
justify the thick client interface, and you can't do that without pretty
graphics, and there just aren't a lot of places in ERP that need pretty
graphics.  Thick clients are really stupid in most ERP environments.


> I thought their AS/SET tool was good at first.  But it failed to keep
up
> with evolution of RPG, etc, and lost most, if not all, of it's
advantages.
>  It couldn't function as a "cash cow".  Even though later releases of
BPCS
> leaned heavily on AS/SET.  About the only enhancement to later
versions of
> RPG is they use they do a CVTRPGSRC and then CRTBNDRPG.  And, other
than
> to get around a few limitations regarding program size, etc that was
only
> to say "See, we generate RPGIV now".  Yes, they still take 10
character
> AS/SET names and convert them down to 6 character RPG names before
> generating the original RPG source, that they then do the CVTRPGSRC
on.
> And I can remember AS/SET customers that didn't even have BPCS.  I
served
> as secretary of the AS/SET User Group.

AS/SET was a dog from day one, although the dog could hunt for a little
while.  We called it "@RPG" internally, because that's all it really
was, RPG with data models.  It was written by CS majors with no real
world business experience, and it showed.  It generated bad code and in
many ways made programmer's lives harder.  Syntax decisions were made
because the AS/SET guys thought we "should code that way".  If it wasn't
for the constant pushback from the development team, you wouldn't have
been able to use that stuff for anything more than a simple maintenance
panel.  Heck, at first they didn't even have the concept of a called
program with no screen I/O!


> I think SSA spent too much time generating pie-in-the-sky theories
about
> development.

I don't know what you mean here.  SSA went bankrupt because they wasted
tens of millions of dollars trying to create a Unix/SQL package that
didn't work and nobody bought.  And the primary reason it didn't work is
because it was done outside of the architectural process that had made
SSA a $500 million company during my tenure.  It was basically an
enormous technical project being run by non-technical people, and that
will always be a disaster.


> But, we still like their ERP package and are a happy customer with
that.

That's what BPCS is.  An ERP package.  And prior to version 5, it was a
really good ERP package. 

Joe