RE: BPCS Version 4.05 CD -- BPCS-L


I would respectfully disagree with Mike.

He cites the primary reason for migrating to 6.X is for support, but I
think the
primary reason for migrating to 6.X is for additional business
functionality
available in 6.X to support your business requirements that version 4.05 CD
does
not have.   I'm sure that 6.X AS/SET poses some IT support challenges, but
I
think the additional functionality available in 6.X makes it worth the
move.

For any users of 4.005 CD that would like an overview of the major changes,
I
can send you a powerpoint presentation that highlights the differences.
Please
respond to my e mail below.
-----------------

While I realize this may provoke a bit of a fuss, I would like to point out
something about BPCS version 6 from my own perspective.  Some of the
programs are definitely not written to be native AS/400 programs.  While
Mr. Benton asserts that "6X AS/SET poses some IT support challenges", my
opinion is that he has woefully understated the point.  BPCS 6X requires
expertise not required on previous releases, and at the same time, has
performance and design issues that make it a completely different package
than its predecessors.

As a single example: In version 6.1.01 of BPCS, ORD700D2, the order
entry/maintenance program, has over 15000 action diagram statements.  This
expands to over 44000 lines of SQLRPG.  You cannot even open the source
member in SEU.  And the SQLRPG makes such heavy use of SELECT INTO that, by
the time you are ready to edit an order, ORD700D2 has over FOUR HUNDRED
open data paths.  On an underutilized model 730, it takes several seconds
to bring up a two-line order for editing.

Why is this?  There are any number of reasons.  The most likely is that the
program was migrated directly from the old "fat client" technology, making
heavy use of the "work files" ECHW and ECLW, especially through SQL calls.
These work records (which didn't even exist in the previous versions) are
read into huge arrays.  In addition, the program often uses SELECT INTO to
get a single field from those (and other) database records.  The heavy use
of SELECT INTO on the ECHW and ECLW is even more disturbing due to the fact
that the program has not one, but two separate logical views over the ECLW
open for update.  Using one of these, or adding an input-only logical file,
is far more appropriate for this type of database access.   This
combination of standard AS/400 database techniques and non-standard SQL
access negates any argument that it was done for "platform independence",
the typical mantra invoked when SQL is used and drastically reduces
performance.  Instead, what you have is a program that seems to have been
built for a different platform and then migrated back to the AS/400 (into
AS/SET, no less), and all the program bloat that that entails.

So given all this, is BPCS 6X bad?  I can't say.  From all accounts, it
does some things wonderfully, and evidently 6.1 is a model of stability as
compared to the original 6.0 release.  However, to say that a shop that is
competent in maintaining and running a business on 4.05CD will suffer only
some "IT support challenges" in a move to 6X is, in my opinion, a
disservice to those clients and a potentially dangerous statement.  This is
NOT a simple "plug in a tape and press a button" upgrade, and some of the
core programs have changed so as to be completely unrecognizable.

Again this is my opinion, heavily biased by my years spent at SSA as the
Manager of Architecture.  I grew up with BPCS from the pre-AS/400 days to
the release of V4.4, which was a very stable, powerful release.  The
current releases may indeed have lots of new features, but BPCS is no
longer a native AS/400 application, and so requires a completely different
implementation and maintenance support team.

Joe

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