Re: Poor Response Times ... BPCS INV (and everywhere else)

Albert,

In a message dated 11/26/01 7:41:06 AM US Eastern Standard Time,
alblopezc@yahoo.es writes:

<<snip>>
> And again, as I said in the previous e-mail, a job of investigating in each
> instalation has to be done, this is standard. I also traveled a lot
> correcting BPCS installs, and most of the time the problems were due to the
> software. If anybody has suffered an implementation of  BPCS on v6.02 or 04
,
> especially at the first releases, knows what I am talking about.

Yes, but I must _vehemently_ disagree with the wholesale installation of
logical files at _ANY_ site.  OK, you researched.  OK, this worked for most
of _YOUR_ clients.  Yes, your offer is quite easy to install and magnanimous
in nature.  But _think_ about it.  Weren't most of your clients similarly
configured?  Weren't most of your clients running the same BPCS modules in
the same manner?

Sorry, but most of our performance questions on BPCS-L involve G/L.  You
should be aware that 90% of my "Fortune 500" clients running BPCS do not
_RUN_ BPCS G/L.  It's too expensive, too involved (G/L _IS_ G/L, despite what
the "old line" SSA thought) and most of them merely want to interface
manufacturing systems to a G/L with which they are happy already (generally
something running on a mainframe at headquarters).

I must also respond to the earlier suggestion that PRTSQLINF is the be-all
and end-all of SQL performance tuning.  Aaaaack, _WAY_ wrong answer.  While a
useful tool, that command only reports from the last time that (observable)
program was run.  Number one, you must run STRDBMON with type *DETAIL against
anyone who's job is having a performance problem to an outfile --  query the
outfile for a QQIDXA (Index Advised) that contains a "Y" and create the
logical file based upon the given index and ensure that this does not make
the problem _worse_ (it can).  Number two, you must ensure that anyone _ELSE_
using the same file does not experience a performance degradation from
actions performed under number one.  Number three, the performance "knee" of
SQL on the AS/400 appears to be about 250 thousand records for any given
file.  The latter means that, should your file exceed the record limit,
applications that formerly worked well in BPCS could start to degrade.

HTH, and I would be more than happy to help anyone interpret their problems.
Please do _NOT_ try to associate V4 or lower performance with V5 or greater
performance...

JMHO,

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

"There are no shortcuts to anywhere worth going." -- Beverly Sills