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




Hi Todd,

ERROR: Connection for read uncommitted not created.

I suspect this line is actually more to the point. From what I've seen, HY010 can be caused by several issues. You should be able to verify if the link relates by running the query on the remote system. If you get results, then "no results returned" is misleading.

If the table is not journaled, then you can't use transactions.

If it really is (and should be) not returning results, then you would catch the error and handle it.

You could also try the type 4 JTOpen driver rather than the native DRDA driver to see if anything differs.

There are enough possibilities that it may take a while to run down through this or other forums, and I'm about out of free time today. Godd luck,


Joe Sam

Joe Sam Shirah - http://www.conceptgo.com
conceptGO - Consulting/Development/Outsourcing
Java Filter Forum: http://www.ibm.com/developerworks/java/
Just the JDBC FAQs: http://www.jguru.com/faq/JDBC
Going International? http://www.jguru.com/faq/I18N
Que Java400? http://www.jguru.com/faq/Java400

----- Original Message ----- From: <TAllen@xxxxxxxxxxxx>
To: "Java Programming on and around the iSeries / AS400" <java400-l@xxxxxxxxxxxx>
Sent: Wednesday, August 20, 2008 10:58 AM
Subject: Re: QSQCLIPKGx


I changed the job and that got rid of the CCSID error. Now I am seeing
different errors:

com.ibm.db2.jdbc.app.DB2DBException: Error occurred in SQL Call Level
Interface - HY010
...
ERROR: Connection for read uncommitted not created.

A bit of searching tells me that HY010 is a sequence error and that the
JDBC drivers were updated as of V5R4 to throw exceptions if a result set is
not returned. This can be overrideen with a property but I'm not sure I
can change that when calling this class.
http://www-1.ibm.com/support/docview.wss?uid=nas12600ac37118304f886256c7500587639

Does anyone have an idea on how to get around this?

Thanks,
Todd





"Joe Sam Shirah"
<joe_sam@bellsout
h.net> To
Sent by: "Java Programming on and around the
java400-l-bounces iSeries / AS400"
@midrange.com <java400-l@xxxxxxxxxxxx>
cc

2008-08-20 09:33 Subject
Re: QSQCLIPKGx

Please respond to
Java Programming
on and around the
iSeries / AS400
<java400-l@midran
ge.com>







Hi Todd,

Take a look at:

http://publib.boulder.ibm.com/infocenter/wpdoc/v510/index.jsp?topic=/com.ibm.wp.ent.doc/wpf/is_cr_rem_db2.html


and scan for "CCSID". I realize you probably aren't using the portal, but
this appears to be the most comprehensive description. Note the
"Temporarily change the CCSID for jobs to 37". You may have other problems

later, but that should allow the package to be created.

If you want to be bored: I talked with the I18N guy (name withheld
because I'm a nice guy) at COMMON, San Antonio, *1997* about the 65535
problem. My own solution was to make 65535 match the system CCSID, like
37,
and make binary an explicit choice with another CCSID, my suggestion being
65534. After all, how many times have you (you being anyone) said, "oh, I
want everything to be binary so no other system can understand it without
its own conversion routine" ???

I realized that would cause come pain, and I thought they could
probably
come up with a better solution, as long as the default wasn't binary, which

explicitly says "no translation." But, I was basically given an it ain't
gonna change. Since then the amount of time lost to 65535 issues is
incalculable. The latest, AFAIK, was to just dump the problem on the
customer. The particularly disgusting thing about it is that those who
initially set up their AS/400 are probably not versed in I18N issues or
even
aware at that point that 65535 will cause so many headaches.

I'm stopping before it becomes a rant (hope it didn't already,) but
there you have it. It just seems to me that with as many smart people as
there are in computing, someone who could do something should have seen
that
one coming. Whatever else one thinks of Java, I18N considerations were
built in from the beginning.

Anyhow, I hope the link above helps with your problem.


Joe Sam

Joe Sam Shirah - http://www.conceptgo.com
conceptGO - Consulting/Development/Outsourcing
Java Filter Forum: http://www.ibm.com/developerworks/java/
Just the JDBC FAQs: http://www.jguru.com/faq/JDBC
Going International? http://www.jguru.com/faq/I18N
Que Java400? http://www.jguru.com/faq/Java400

----- Original Message -----
From: <TAllen@xxxxxxxxxxxx>
To: "Java Programming on and around the iSeries / AS400"
<java400-l@xxxxxxxxxxxx>
Sent: Wednesday, August 20, 2008 8:49 AM
Subject: RE: QSQCLIPKGx


To answer the questions:

- No, WAS is not trying to connect to itself. It runs on a separate
system
and connects to a database system.

- The SQL is a simple stored procedure call

- The System.Out log shows the error for the missing SQL package in the
QGPL library
This is followed by a stack trace, which was caused by the JDBC
connection
error

- The target system is not on the same box

The error seems to point to an i-specific problem but don't know what
that
is yet.

Thanks,
Todd





"Gary L Peskin"
<garyp@xxxxxxxxxx
om> To
Sent by: "'Java Programming on and around
java400-l-bounces the iSeries / AS400'"
@midrange.com <java400-l@xxxxxxxxxxxx>
cc

2008-08-19 17:20 Subject
RE: QSQCLIPKGx

Please respond to
Java Programming
on and around the
iSeries / AS400
<java400-l@midran
ge.com>






We should take a step back, I think, since this works fine on your PC. I
-suspect- that this has to do with your trying to connect back to your
WAS
6.1 V5R4 system from itself using DRDA.

What does the SQL statement that you're passing to the JDBC driver look
like? Does the stack trace for the "SQL package..." error indicate that
this exception arises from an action being initiated by your program or
by
WAS itself? Is the DB2/400 system that you're trying to connect to on
the
same box as WAS. If so, have a look at the Integrated Solutions Console
at
Resources -> JDBC -> Data Sources -> Database name. I don't have an
iSeries
copy of WAS but I'm used to one on zSeries z/OS. The Database name
should
be blank if you're trying to connect to a local instance to DB2.

HTH,
Gary

-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx
[mailto:java400-l-bounces@xxxxxxxxxxxx]
On Behalf Of TAllen@xxxxxxxxxxxx
Sent: Tuesday, August 19, 2008 1:31 PM
To: Java Programming on and around the iSeries / AS400
Subject: Re: QSQCLIPKGx

The user CCSID is set to the system value, which is 65535 (none), as are
all users. I don't know that I can change that.

The exact error message is:

java.sql.SQLException: INTERNAL ERROR: Creation of DB2Driver object for
registering with DriverManager failed. ->
com.ibm.db2.jdbc.app.DB2JDBCDataException: CCSID value is not valid.

This is the result of calling the following Java command, asnoted in the
IBM page.

JAVA CLASS(com.ibm.db2.jdbc.app.DB2PackageCreator) ('system' 'user'
'password')

Thanks,
Todd





CRPence
<CRPbottle@yahoo.
com>
To
Sent by: java400-l@xxxxxxxxxxxx
java400-l-bounces
cc
@midrange.com

Subject
Re: QSQCLIPKGx
2008-08-19 15:09


Please respond to
Java Programming
on and around the
iSeries / AS400
<java400-l@midran
ge.com>






A SWAG given no details of what are the "several errors that the
CCSID value is wrong", in neither message ID nor text:

For the user profile under which the SQL work is being performed,
issue the CL request on a command line for the server:
DSPUSRPRF TheUserProfile /* Review the CCSID setting */

Presumably the CCSID setting shown by the DSPUSRPRF request is *HEX
or 65535, instead of an EBCDIC CCSID which enable conversion to ASCII.
The recovery is probably achieved by issuing the CL request on a command
line for the server, then establishing a new connection with that user:
CHGUSRPRF TheUserProfile CCSID(Valid_CCSID) /* A valid CCSID for US
English EBCDIC is 37 */

Regards, Chuck

TAllen@xxxxxxxxxxxx wrote:
> I have a WAS 6.1 server on a V5R4 system that is throwing the
following
> error when a JDBC connection is attempted.
>
> com.ibm.db2.jdbc.app.DB2DBException: SQL package QSQCLIPKGA in QGPL
not
> found at DRDA Server.
>
> Searching around brought me to the following page.
>
>
https://www-


912.ibm.com/s_dir/slkbase.NSF/1ac66549a21402188625680b0002037e/460d52a956268


f
57862569de004e16d8?OpenDocument

>
> This looked promising but when I run the Java class I get several
errors
> that the CCSID value is not valid.
>
> Has anyone seen this before or have any suggestions? By the way, this
> works fine on a Tomcat server running locally on my PC.


--
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) mailing list
To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.



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.