We have a customer using TCP/IP communications to access a client/server
application between the AS/400 and PC.
They have complained whereby the above program is taking up a whopping
amount of CPU, and basically grinding their system to a halt.!!
Can anybody throw any light on the above ?
Caroline
QZDASOINIT is a prestart job serving ODBC connections through Client
Access. It runs at priority 20, which cannot be changed as it runs as
QUSER (you can change it at run-tume, but the default for the
next job remains 20).
Since most ODBC connections involve SQL, there's always a chance that
the AS/400 decides to build an index for data access - when this
happens, QZDASOINIT can take up to 90% CPU, leaving you with nothing to
do but to end the job with *IMMED setting, and to add some logicals the
Query Optimizer might consider instead of creating a new index.
Good luck,
Mirko
In article <SE7C3.574$s4....@news.indigo.ie>,
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
QZDASOINIT is an ODBC server job... if it takes a whopping amount of CPU, it
usually means that a not properly written SQL statement is being executed by
a client (see joblog for knowing the client).
Regards,
Paul
-----------------
BLACKIE wrote in message ...
Anybody know the functionality of the QSERVER subsystem and the program
QZADASOINIT.
We have a customer using TCP/IP communications to access a client/server
application between the AS/400 and PC.
They have complained whereby the above program is taking up a whopping
amount of CPU, and basically grinding their system to a halt.!!
Can anybody throw any light on the above ?
Caroline
The contents of this message express only the sender's opinion.
This message does not necessarily reflect the policy or views of
my employer, Merck & Co., Inc. All responsibility for the statements
made in this Usenet posting resides solely and completely with the
sender.
Jason Hanse
Should be possible to change the QPWFSERVER class instead? Although I would
recommend allocating a pool to QSERVER if you are planning to use
client/server stuff a lot.
> Since most ODBC connections involve SQL, there's always a chance that
> the AS/400 decides to build an index for data access - when this
> happens, QZDASOINIT can take up to 90% CPU, leaving you with nothing to
> do but to end the job with *IMMED setting, and to add some logicals the
> Query Optimizer might consider instead of creating a new index.
Erm, yes, but with a bit of careful planning...
____
Paul