Re: Overall BPCS performance -- BPCS-L

Dan,

In a message dated 98-10-08 14:39:42 EDT, you write:

<<snip>>
> Certainly, as a BPCS Y2K solution vendor, I feel that he had a brilliant 
>  alternative to 6.x.x.  As well, he most probably still has enough time to 
>  century-enable his 5.1 implementation and put off the 6.x.x pain for some 
>  time.
>  
>  However, this discussion about the poor 6.x.x performance provokes another 
>  thought:
>  
>  Why does everyone seem to accept that BPCS 6.x.x _SHOULD_ command such 
>  incredible AS/400 resources?

Errrrr, don't get me started!  Back in the 5.x days, I was willing to write it
off to the "CASE Crunch" of moving everything into AS/Set.  MAPICS users
moving to the Synon version and J.D. Edwards users moving to WorldVision-
produced code experienced the same thing.  Then came V6 and its' ubiquitous
SQL, and the code note "To improve performance in the UNIX environment, no
effect plus or minus on the AS/400" -- ERRRRRRRRRRR!  _SURE_ there's no
difference if you're testing of the BPCS education database, making a couple
of PENS or LAMPS, but just _TRY_ and make a _REAL_ product!

SSA _SHOULD_ have tested with a database containing more than 200K records in
a few files (the breakover point for SQL performance on the AS/400).  But
hindsight is 20/20.  At least Peter G is trying to give us some hints here
now.  The remainder of this rant will be under your IBM comment...

>  There has not been that much of an increase in useful business
functionality 
>  over prior BPCS versions.  So it must be architectural or technical 
>  underpinnings that require all of those resources.?.?.?.

Oh, its' there in the database, its' just "not available in this release"
>8-(.  You hit the nail on the head here, though.  Architectually and
technically, a well-written AS/Set program is 2.5 times larger than the
equivalent RPG program -- and these are _NOT_ well-written AS/Set programs for
the most part.  But beyond _THAT_, most of the SQL was inserted to make it
easier to convert BPCS to UNIX!  Rather than come up with routines in their
RPG converter that handled the various I/O statements without fail, it was
easier to hit an EXECSQL and move that into a UNIX SQL statement.  SQL is far
more efficient on a UNIX box than it is on an AS/400 -- yet the UNIX users are
screaming about performance too!

>  Are people really convinced that the architectural merits of BPCS 6.x.x are
>  worth having to pay for all that IBM can muster??

Heck NO!  Like AS/Set, the only improvements made in BPCS over the last five
years have been market-driven.  I once worked for an AS/Set agent firm, we and
our customers wanted:  1. An improved user interface -- we got IKS and MLS.
2. An improved Report Layout function -- we got *JOB on the OUTQ.  3. Improved
program generation that created RPG taking advantage of functions added since
V1R3 -- we got more built-in functions that supported C/S BPCS.  Why?  Because
they wanted to sell more AS/Set (before they decided to take it off the
market).  Servicing existing users was not in the equation.

And BPCS?  Slow C/S functions that primarily supported accounting functions
(the department that often determines what package to buy) because SSA was
sick of installing BPCS with SW2K (now Infinium) as the financial portion.  An
order entry package that requires quadrupling your O/E clerk staff.  But wait!
There's more!  You also cannot customize (these most customized of all BPCS
modules) without hiring SSA to do it FOR YOU!  Why?  To sell more BPCS at the
top level and for several other reasons:

1.  Facilitate the move to UNIX because they thought that the AS/400 was dead.
2.  To showcase their new development product, first DOCA (which morphed into
the "architecture"), then NEWI (which morphed into the "database") and now ODW
(which is the old AS/Set IWS morphed into a supposedly-viable development
tool).  RANT HERE (ignore if desired):  SSA worked on IWS for over FIVE YEARS
without coming up with a viable product, WHAT THE HECK made them think they
could develop a new product in 18 months?  Riz Shakir (four hours late)
demonstrated DOCA at the Fall '95 AS/Set User's Group meeting the Saturday
prior to that COMMON and it was due 1Q96 -- WHERE THE HECK IS IT? END OF RANT.
3.  Place (not yet populated) fields in the database that support functions
that SSA has promised prospective buyers for years.
4.  Enhance their consulting revenue once they realized that idiot clients
were willing to pay them for modifications to the C/S portion that they won't
provide the source for.
5.  To come out with a new release because, well, all the other vendors are
doing it.

>  (By the way, I AM truly impressed with what IBM has done for AS/400 
>  performance and I'm sure SSA must be grateful to IBM.)

It is, indeed, _VERY_ impressive.  However, it was done to support "openness"
and web serving, not to help SSA (although I hear that IBM _was_ the "mystery"
investor that bailed SSA out of their initial financial problems).  If SSA
planned on changing their data access paradigm, they _SHOULD_ have tested with
a realistically-sized database instead of the wimpy "education" one.  The
problem is, they didn't know how the AS/400 worked in the first place (I've
seen their in-house /400's) and now they're porting it to platforms that they
know even less.  They should have had (and probably did, but ignored them)
/400 staff on site that told them that moving everything to SQL was a bad
idea.  Instead, they chose to listen to their Oracle and HP/UX gurus who said
SQL screamed (and it _does_ in that environment).  So they took code that was
inefficient on its' base platform, translated it inefficiently to another
platform, and aliented _ALL_ of their client base.

That said, the new regime at SSA appears (at this time) to be trying to
rectify this mess for the /400 folks.  Unfortunately, they also seem to be
leaving the UNIX users in a lurch at the same time.  Through their public
statements, the feeling that future UNIX development is dead pervades --
contrary to their other public statements that UNIX comprises 16% of their
installed base.  Like IBM, "all future development will be directed toward NT
and JAVA".  Yeee-haw, _another_ proprietary development tool from your friends
at SSA -- I can't wait (another five years)!  Seriously, though, we can all
hope that Steuk has not yet fully plumbed the depths of SSA's problems, and
will eventually announce more coherent future plans than have appeared to
date.  I'm just happy that V7 development has been suspended until V6 has been
stabilized...

JMO,

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-Mail:  DAsmussen@aol.com

"I feel like a fugitive from the law of averages." -- Bill Mauldin
+---
| 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
+---