Re: Slow AOE

Down inside the bowels of AOE lies the pervasive AO006. Any time you deal 
with anything to do with order lines this is the program that controls and / 
or does 90% of the work. This includes stock checking, allocation, etc, etc. 
Any time you update a single line, all of the aforementioned checks are 
repeated for every line within the order. This leads to a huge amount of 
overheads but it is necessary if you allow the same product to appear on an 
order more than once.

This problem was acknowledged by JBA at least 4 years ago that I know of but 
no significant work has ever been done to correct the methods employed. The 
major reason is that AOE was never intended for use in an environment 
requiring many order lines. Say for instance you are in the hi-tech 
business, then the original JBA designers anticipated that the average order 
will have a max of 10 order lines. In this environment, AOE works well. 
Remember that AOE raison d'etre was to be as a 'doing a deal with the 
customer' type pf order entry. Hence the emphasis on margins and stock 
commitment.

The same hi-tech business would probably also have a spares order entry 
requirement. This may involve sales orders with several hundred order lines. 
I think JBA anticipated that users would use Transciptional Order Entry for 
these types of orders. That would also be my rec since you probable would 
have less of a 'do a deal' requirement in the very large order environment.

The problem of course lies in the fact that once AOE is installed, all other 
forms of order amendment are disabled. In my opinion the original designers 
just didn't anticipate this problem.

Without doing a re - write of the basics of AOE have a look at the WA and WB 
work files, avoid using order line extension files  and try where possible 
to use Transcriptional Order Entry for the Order Entry.

Hope this helps.

Regards

Murph.

>From: randy_smith@omron.com
>Reply-To: JBAUSERS-L@midrange.com
>To: JBAUSERS-L@midrange.com
>Subject: Re: Slow AOE
>Date: Tue, 8 Feb 2000 18:00:47 -0600
>
>
>There may also be some other things to check ...
>Look at the order entry work files which should be reorganized, they are
>probably HUGE since every time you open an order it writes records.
>Also you may want to consider selectively deleting records from the audit
>files, since even if you change a comment, all lines and all information
>gets written out to the audit files, even if you are opening it up to
>"enquire" on something and don't change it.
>Also, there may some very clumsy coding with indicators on "call"
>statements which keep the program from dumping, but still look throughout
>the entire AS/400 for an object which may not be there because not
>installing certain modules.  Manufacturing comes to mind.  If performance
>is key to your operation, I'd invest some time and very simple mods on
>avoiding these performance issues (JBA doesn't call them bugs because the
>software works, albeit slowly).
>I think you will find the biggest hit comes at firing up the order, or
>opening it for change.  I've seen a single user take 43% of the entire
>system (only for a short amount of time, but resource contention adds up
>fast at that rate.)
>
>There are lots of ways, depending on how you use the system (Advanced
>Pricing, for example) that can drag down the system, more specificity may
>allow others to identify the trouble areas : )
>
>Randy Smith
>
>
>
>
>Dan Thomas <DThomas@lpw-mdi.com>@midrange.com on 02/08/2000 04:02:24 PM
>
>Please respond to JBAUSERS-L@midrange.com
>
>Sent by:  owner-jbausers-l@midrange.com
>
>
>To:   "'JBAusers-l@midrange.com'" <JBAusers-l@midrange.com>
>cc:
>
>Subject:  Slow AOE
>
>
>There is no doubt that AOE is a performance hog, but it does run OK on our
>system (620 / 2179 w/ 1GB RAM) which is lightly loaded.  We do need many of
>the features provided by AOE, so for us it is the only alternative.  We've
>noticed it takes a long time (5+ seconds) to load an large order (25+
>lines)
>for amendment, but haven't had complaints about initial entry of a large
>order.  It reprices each line every time you amend an order.  It also
>checks
>for credit issues that might cause an order to be suspended.  IMO, it would
>take a lot of resources to "improve" AOE to make it faster and you would be
>better off buying more hardware.  It is a huge, complicated suite of
>program
>that doesn't use many shared routines.  Angus, it would be interesting to
>hear your machine configuration, typical number of active users, size of
>orders with problems and the response time you are experiencing.
>
>Dan Thomas
>Sr. VP Information Systems
>Medical Distribution, Inc.
>4500 Progress Blvd
>Louisville, KY  40218-5058
>Phone (502) 454-9013 ext 120
>email  DThomas@lpw-mdi.com
>
>
>-----Original Message-----
>From: David Shea [mailto:dshea@arctools.com]
>Sent: Tuesday, February 08, 2000 10:05 AM
>To: JBAUSERS-L@midrange.com
>Subject: Re: System pools
>
>
>Angus:
>
>Try the performance adjustment.  Generally, it's pretty good.
>
>Does order entry run acceptably for small orders?  Define 'many lines'...
>10? 100? 1000?
>
>You need to do a couple things to figure out where your performance
>problems
>are coming from.  Does the software do any SQL or OPNQRYF?  Watch the jobs
>as they run.  Do you see very high CPU but little I/O?  High CPU and low
>I/O
>reeks of logical file problems - you're either building them (SQL or
>OPNQRYF), or rebuilding them (LF with the REBLD option turned on).  Or, are
>you seeing record locks?  In this case, you'll see LCKW on WRKACTJOB.
>
>One way to speed things up is to get rid of old data.  You might have files
>that simply need to be reorganized, or you might see significant
>performance
>improvement by purging and archiving data.  Check out
>http://www.arctools.com .  ARCTOOLS is a disk optimization utility that can
>help you reorganize the files you've got, and it will also help you purge
>and/or archive your data.  If you have an existing purge-only routine, it
>will add the archiving feature without programming.  If you don't have a
>purge routine for a particular file, it can purge and archive data without
>programming and without locking files.
>
>Good luck.
>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Purge and Archive your AS/400 Data Without Programming with ARCTOOLS (tm)
>DCSoftware, Inc.
>(508) 435-8243
>(508) 435-4498 (fax)
>http://www.arctools.com
>mailto:info@arctools.com
>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>----- Original Message -----
>From: "Angus Appleby - Unwins Seeds" <aappleby@unwins-seeds.co.uk>
>To: <JBAUSERS-L@midrange.com>
>Sent: Tuesday, February 08, 2000 5:44 AM
>Subject: System pools
>
>
>Hi
>
>We have terrible problems with the speed of entering orders using advanced
>order entry because we have many orders and many lines on each order. We
>have just upgraded our memory to 896Mb to try and alleviate this, and have
>been recommended to leave the performance adjuster on at all times. Does
>anyone else have similar problems? How do you set your pool sizes?
>
>Angus
>
>+---
>| This is the JBA Software Users Mailing List!
>| To submit a new message send your mail to JBAUSERS-L@midrange.com.
>| To subscribe to this list send email to JBAUSERS-L-SUB@midrange.com.
>| To unsubscribe from this list send email to
>JBAUSERS-L-UNSUB@midrange.com.
>| Questions should be directed to the list owner: doug333@aol.com.
>+---
>+---
>| This is the JBA Software Users Mailing List!
>| To submit a new message send your mail to JBAUSERS-L@midrange.com.
>| To subscribe to this list send email to JBAUSERS-L-SUB@midrange.com.
>| To unsubscribe from this list send email to
>JBAUSERS-L-UNSUB@midrange.com.
>| Questions should be directed to the list owner: doug333@aol.com.
>+---
>
>
>
>+---
>| This is the JBA Software Users Mailing List!
>| To submit a new message send your mail to JBAUSERS-L@midrange.com.
>| To subscribe to this list send email to JBAUSERS-L-SUB@midrange.com.
>| To unsubscribe from this list send email to 
>JBAUSERS-L-UNSUB@midrange.com.
>| Questions should be directed to the list owner: doug333@aol.com.
>+---

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

+---
| This is the JBA Software Users Mailing List!
| To submit a new message send your mail to JBAUSERS-L@midrange.com.
| To subscribe to this list send email to JBAUSERS-L-SUB@midrange.com.
| To unsubscribe from this list send email to JBAUSERS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: doug333@aol.com.
+---