× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.