RE: Antwort: QZDASOINIT and sytem performance?

I agree with everything Ralf says except that you can blame the SQL
implementation to the extent that you MUST TUNE and/or DESIGN your apps
and database design specifically for SQL usage. Blame is not the proper
word. SQL is just a different (and powerful) access method, combined
with elegant "programming" functions, but it falls short of a
programming language such as Java, RPG, VB, etc. And yes, you may very
well need to upgrade your current AS/400 computer hardware
(processor(s), memory, Dasd space) from what you had running native or
non-sql applications. Both options were suggested to us by IBM Rochester
after monitoring our new SQL based application.

Unfortunately our management switched to an Intel based server, more
processors, more memory and more Dasd, running Microsoft SQL Server. The
application as a whole seems to run better, (as it should with doubling
the machine size) but I believe it degrades fast as additional loads are
placed on it. I personally opted to upgrade the AS/400 hardware, but the
non-IBM solution was $dollars cheaper on paper. I believe it will cost
much more as time goes on.

George    

-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx
[mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of
ralf.petter@xxxxxxxxxxx
Sent: Friday, October 21, 2005 1:10 AM
To: Java Programming on and around the iSeries / AS400
Subject: Antwort: QZDASOINIT and sytem performance?

Hi TitanRebel!

I am sorry, but you can not blame SQL, nor can you blame Java for the
bad 
performance. The only reason for the bad performance is either bad 
database design or bad coding of your SQL statements in your
application. 

First of all are you using Prepared Statements with parameter marker?
Do you have the correct sort sequence defined at JDBC level and database

level. If your access path are using another sort sequence then defined
in 
your JDBC connection. the JDBC driver can not use this access pathes and

have to create new one.
Debug the QZDASOINIT Job and see what suggestions the query optimizer 
makes.
Use the new profiling feature in WDSc 6.0 to find the methods in your
Java 
programm which performs weak.

I hope this tips helps.

Greetings from Austria

Ralf




TitanRebel <TitanRebel@xxxxxxxxxxx> 
Gesendet von: java400-l-bounces+ralf.petter=artweger.at@xxxxxxxxxxxx
20.10.2005 17:22
Bitte antworten an
Java Programming on and around the iSeries / AS400 
<java400-l@xxxxxxxxxxxx>


An
Java Programming on and around the iSeries / AS400 
<java400-l@xxxxxxxxxxxx>
Kopie

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