|
There are a couple of things that can be done. First one is to have the sys admin change the QZDASOINIT prestart jobs to do the following. 1. Run with a priority of 50. The factory default is priority 20. Priority 20 means the QZDASOINIT jobs are running at the same priority as interactive jobs so they can impact performance. Changing them to run at a priority of 50 puts them in the category of batch jobs. 2. Change the QZDASOINIT prestart job to be reused more often. There are also something you can do. Optimize your ORDER BYs to utilize existing access paths. If you're sequencing in such a manner that an existing access path can't be used you're application can use a LOT of cpu. Particularly if it is over tables containing a large number of records. For information on how QZDASOINIT jobs determine what access path to utilize (you don't actually use the one named sometimes) Google Query Optimizer or go to the IBM InfoCenter and search on Query Optimizer. -----Original Message----- From: java400-l-bounces+gary.monnier=powertech.com@xxxxxxxxxxxx [mailto:java400-l-bounces+gary.monnier=powertech.com@xxxxxxxxxxxx] On Behalf Of TitanRebel Sent: Thursday, October 20, 2005 8:22 AM To: Java Programming on and around the iSeries / AS400 Subject: QZDASOINIT and sytem performance? QZDASOINIT prestart jobs service JDBC requests. When running, they tend to "grab" a lot of CPU cycles. I assume IBM designed it this way. Because of this, my Java applications typically get blamed for causing poor overall system performance (even for interactive jobs). Is SQL (Java or RPG) more processor intensive than direct file access via RPG? If so, does anyone know of any guidelines for "up-sizing" the iSeries box as legacy RPG applications get converted to Java or RPG with SQL file I/O? Also, can the QZDASOINIT jobs cause performance problems for Interactive jobs? I've always thought that they would NOT effect interactive jobs because of the "Interactive Card Tax" that supposedly isolates x CPW just for interactive jobs (Batch jobs can't use it... right??). Any links or advice would be appreciated. Thanks.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.