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

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-----
[] 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.


This thread ...

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