V6 (was Re: Update from WABUG (Western Area BPCS User Group) Meeting)

Bill,

In a message dated 98-08-14 11:37:08 EDT, you write:

> You do contradict yourself, but do reinforce my point which I did not state 
> well.

Not really contradicted, just changed my mind midstream ;-)!  Just like
bloated PC software, V6 is going to require a hardware upgrade if you're like
most shops and already running tight on resources.  V4R3 will handle SQL
_MUCH_ better.

> I should correct myself by saying that I will never go to V6 as long as it
is
>  codeveloped with UNIX.  The true statement is - I will never go to V6 as
long as I
>  have to upgrade my box several levels, and work with a software package I
can 
> only "configure" but not customize.  The windmill that I continue to joust
is that the
>  package has suffered greatly trying to serve two masters and they would do 
> themselves a great favor by rethinking this policy.

Again, I'm afraid you're stuck.  I hate the policy too, and wish that they had
stuck with their original client/server model wherein the server programs were
written to the box on which they were running.  I thought that ODW was now GA
so that customization is no longer an issue -- true?  One can only imagine
what the UNIX users are going through, given that they run a package that is
inefficient on its' native platform that has been converted to run on theirs!

>  > . . . and knowing a few simple techniques
>  > can fix what SSA didn't see when they tested performance against the 
> infamous
>  > education database (Can you say PENS?  I knew you could!).
>  
>  Dean, you have supplied at least one example of helping the performance.  
> Would you care to share the full suite of tips?  Maybe identifying which
version(s) 
> each tip applies to will help everyone.  I encourage everyone to share their
> performance tips.  Here's mine:  ACR300 performance got you down?  You may 
> have one of the versions of code that is written to perform a security check
on 
> every record it reads for the inquiry screens.  Modify the code to check to
see if the 
> company has already been checked through security.  In our case, company 
> security was not necessary, so it was skipped entirely. (I just checked CD
and it 
> seems they have corrected this problem).

Hard to deliver a full suite, given that every installation is different.  We
had one plant that had no problem with MRP performance on their box running
5.1.01, while another on the exact same version was _DYING_!  Plant 1 had
fairly shallow bills of material, while plant 2 was nested _FAR_ deeper.
Turns out that, when SSA put the SQL in to delete planned orders, they left in
the DOW loop for deleting them natively (yes, proves your point again) --
although the SQL deleted all necessary records on the first pass, it kept
trying again and again for the same records (fixed with a BMR).

I think I've done this before, but I would offer the following for _ALL_
AS/400 releases that contain SQL:

1.  Check OGS Online frequently for "performance" BMRs against programs in
question, but _DO NOT_ order BMRs if you're not having a problem -- there is
often the "BMR to take out the BMR" in a week or so.

2.  Perform a STRDBG UPDPROD(*YES) before calling a poorly performing program.
When done, check the joblog for any "Access path suggestion" messages and
either through DDS or the SQL CREATE INDEX command, create the suggested
access path.  Test again (after ENDDBG) to see if the program performs better.
Sometimes the suggestions are inaccurate due to a poorly written SQL statement
and can actually _SLOW_ performance.

3.  Run the PRTSQLINF command on offending programs, and see which statments
are taking the longest.  If there are no access path suggestions under 2,
check with HelpLine and see if they are working on the problem -- if not,
report it so they will be.

Regards!

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

"Sleep, riches, and health, to be truly enjoyed, must be interrupted." -- Jean
Paul Richter
+---
| 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
+---