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