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: email@example.com To: "'JBAusersfirstname.lastname@example.org'" <JBAusersemail@example.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:firstname.lastname@example.org] 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:email@example.com +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ----- Original Message ----- From: "Angus Appleby - Unwins Seeds" <firstname.lastname@example.org> 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: email@example.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: firstname.lastname@example.org. +--- +--- | 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: email@example.com. +---
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.