RE: QZDASOINIT and sytem performance?

  We ran into the same thing.  ANy ODBC/JDBC connections are handled by
QZDASOINIT. 
  Furthermore, the QZDASOINIT was running at a very high priority, so while
it was not "Interactive" per se, it might as well have been.
  This job seems to behave itself much better in V5R3 than it did in R2 or
prior, using much less overall system resource.  However, our V5R3 box is
much bigger than the R2 was, so that may account for this.  Anyway, people
have stopped complaining.

  Here's a link to a previous converation about this:
http://archive.midrange.com/midrange-l/199909/msg00680.html

  If this doesn't help, i'll try to find and forward some of the stuff I
found and forwarded to our sysadmin.  I dont recall now exactly what that
entailed, but I do remember that it had to do with changing prirorities,
subsystems, and memory allocations for the job (I think)

  Bottom line, QZDASOINIT is a hog.


-----Original Message-----
From: java400-l-bounces+joe.hayes=fiserv.com@xxxxxxxxxxxx
To: Java Programming on and around the iSeries / AS400
Sent: 10/20/2005 10:22 AM
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.