MIDRANGE dot COM Mailing List Archive



Home » SYSTEM21 » February 2000

Re: Slow AOE



fixed


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






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact