Re: SQL statements through JDBC causing QPSRVDMP's - Resolved (for now)

Dan,

Although updating the jar didn't help, I found another V5R4M0 box that was at a different CUME/group level that I could try this on and the queries ran faster and without the dumps. So, it IS a PTF level issue, I just don't know what PTF's are causing/solving the problems. The box these run OK on is showing "Not Installed" on the CUME and all the PTF Groups so it would be a WAG to try to figure out what is going right at the moment. Knowing that the queries WILL run on some group level is all I need for now. Which level is something I'll have to figure out.

Pete


dkimmel@xxxxxxxxxxx wrote:

Pete,

First, make sure you have a good, current copy of jt400.jar. I've had
problems with some of them. Download the current one from
https://sourceforge.net/projects/jt400.

Second, make sure you have the DB2400 ptf's. Latest CUM is not good
enough, usually.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Pete Helgren
Sent: Friday, January 25, 2008 1:11 PM
To: Midrange Systems Technical Discussion
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

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.