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



Might be an issue with the query engine.
There are probably SQE traces in the IFS, VLOGs and perhaps a problem you
can report (WRKPRB).

Since you have a joblog, you may also want to search for an existing PTF (if
there is one) using some eye-catching keyword:

http://www-912.ibm.com/ImprovedSearch/searchoptions.jsp

If that doesn't yield any APARs/PTFs, open a PMR with IBM. I'm sure they'll
be able to figure out what's happening with the joblog and other traces
available to them.

BTW, you can see what queries are running in a number of ways. One of the
easy to use ones is database monitor (STRDBMON). Other is JDBC exit point.
Not sure knowing what the query is will help you though, but dbmon also
captures errors.
Also, the fact that your Java tool doesn't maintain persistent connections
is hurting your performance (QZDASOINIT jobs disappear/reappear quickly).

HTH, Elvis

Celebrating 11-Years of SQL Performance Excellence on IBM i5/OS and OS/400
www.centerfieldtechnology.com


-----Original Message-----
Subject: SQL statements through JDBC causing QPSRVDMP's

Not exactly sure where to go with this so I'll start here on Midrange...

I have an application that uses JDBC to connect to a database. This app
is DB agnostic (AFAICT). I created a collection/table on the System i
using interactive SQL to manually enter the statements to create the
DB. I am using jt400.jar to connect. All seemed well.

The actual internals of the program, the actual SQL statements sent over
the wire, are not known to me. The app itself takes care of generating
the SQL and retrieving the results. The application was EXTREMELY slow
using the jt400.jar and when I switched to a MySQL JDBC connection,
things speeded up with sub-second response times. Curious as to what
was happening, I switched back to the jt400.jar and watched the
connections using WRKODBCJOB (Bryan Dietz's great utility). It was
interesting as connections were briefly made, then disappeared. Made,
then disappeared. I managed to view the job log of one of the
connections while it was in transit and saw the following:

Attributes of value number 5 in field HVR0005 not valid.
80000000 00000000 272e194a d2411890\nWSQCQDT@:80000000 00000000 272e194a
d2411890\nWSQPAS@: 80000000 00000000 272e194a d2000a00\nCURSOR NAME IS
FILE \nSTMT NAME IS FIFAATTALL0004 \nPACKAGE NAME IS in
library \nPROBLEM WITH QDT FOR STMT# 18, QDT# 1, OCLE 1\nQDT@:80000000
00000000 272e194a d2411890\nWSQCQDT@:80000000 00000000 272e194a
d2411890\nWSQPAS@: 80000000 00000000 272e194a d2000a00\nCURSOR NAME IS
FILE \nSTMT NAME IS FIFAATTALL0004 \nPACKAGE NAME IS in
library \nPROBLE
Dump output directed to spooled file 156, job 030309/QUSER/QZDASOINIT

Some of these dumps are thousands of pages long. All in (to me)
unreadable Hex. Not much use.

The System is V5R4M0. They are on DB Group 13 (!)

I know *something* is amiss here but I can't see the SQL statements that
are causing the dumps. More interesting is the fact the application
does work (albeit slowly). The tables are properly
created/read/updated/deleted. But something is definitely amiss. Where
should I start?

Pete


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.