You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Myrna van Lunteren (JIRA)" <de...@db.apache.org> on 2005/09/21 21:43:34 UTC
[jira] Created: (DERBY-583) networkserver does not return error message strings in native encoding to ij on zseries
networkserver does not return error message strings in native encoding to ij on zseries
---------------------------------------------------------------------------------------
Key: DERBY-583
URL: http://issues.apache.org/jira/browse/DERBY-583
Project: Derby
Type: Bug
Versions: 10.1.1.0
Environment: OS/390 (zseries) 1.06, ibm 1.4.2 jre
Reporter: Myrna van Lunteren
Fix For: 10.2.0.0
When running ij on an OS/390 without specifying any encoding or locale properties, and starting network server without any locale properties, various error messages do not get converted into the native encoding.
Thus the messages are unreadable and not helpful.
The problem is not limited to ij, just easy to reproduce with ij.
Some errors return readable message strings are returned with jcc, but not with derbyclient, for instance the test lang/forupdate.sql has this line in it:
select i from t1, t2 for update;
which on linux & windows results in an error message 42Y90, "FOR UPDATE is not permitted in this type of statement." On OS/390 this error message is readable with jcc, but with derbyclient, only the string 'ERROR' is readable. Other messages - especially those with indirection in it like error 42X04 are equally unreadable with both clients.
To reproduce 1 situation:
- start networkserver
- in another shell window, use the following string to run the in.sql file & save the output for jcc-client and derbyclient respectively:
----------
java -Dij.database='jdbc:derby:net://localhost:1527/wombat3;create=true' -Dij.retrieveMessagesFromServerOnGetMessage=true -Dij.protocol=jdbc:derby:net://localhost:1527/ -Dij.driver=com.ibm.db2.jcc.DB2Driver -Dij.user=APP -Dij.password=APP org.apache.derby.tools.ij in.sql > jcc.out 2>&1
----------
java -Dij.database='jdbc:derby://localhost:1527/wombat2;create=true' -Dij.protocol=jdbc:derby://localhost:1527/ -Dij.driver=org.apache.derby.jdbc.ClientDriver -Dij.user=APP -Dij.password=APP org.apache.derby.tools.ij in.sql > client.out 2>&1
----------
in.sql contains:
----------
drop table a;
create table a (a int);
insert into a values (2342323423);
disconnect;
exit;
----------
I'll attach a jar with the .out files and in.sql. This means that the out files are in EBCDIC, to read them, one needs to run them through native2ascii -encoding Cp1047.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-583) networkserver does not return error message strings in native encoding to ij on zseries
Posted by "Myrna van Lunteren (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-583?page=all ]
Myrna van Lunteren updated DERBY-583:
-------------------------------------
Attachment: ijzrepro.jar
> networkserver does not return error message strings in native encoding to ij on zseries
> ---------------------------------------------------------------------------------------
>
> Key: DERBY-583
> URL: http://issues.apache.org/jira/browse/DERBY-583
> Project: Derby
> Type: Bug
> Versions: 10.1.1.0
> Environment: OS/390 (zseries) 1.06, ibm 1.4.2 jre
> Reporter: Myrna van Lunteren
> Fix For: 10.2.0.0
> Attachments: ijzrepro.jar
>
> When running ij on an OS/390 without specifying any encoding or locale properties, and starting network server without any locale properties, various error messages do not get converted into the native encoding.
> Thus the messages are unreadable and not helpful.
> The problem is not limited to ij, just easy to reproduce with ij.
> Some errors return readable message strings are returned with jcc, but not with derbyclient, for instance the test lang/forupdate.sql has this line in it:
> select i from t1, t2 for update;
> which on linux & windows results in an error message 42Y90, "FOR UPDATE is not permitted in this type of statement." On OS/390 this error message is readable with jcc, but with derbyclient, only the string 'ERROR' is readable. Other messages - especially those with indirection in it like error 42X04 are equally unreadable with both clients.
> To reproduce 1 situation:
> - start networkserver
> - in another shell window, use the following string to run the in.sql file & save the output for jcc-client and derbyclient respectively:
> ----------
> java -Dij.database='jdbc:derby:net://localhost:1527/wombat3;create=true' -Dij.retrieveMessagesFromServerOnGetMessage=true -Dij.protocol=jdbc:derby:net://localhost:1527/ -Dij.driver=com.ibm.db2.jcc.DB2Driver -Dij.user=APP -Dij.password=APP org.apache.derby.tools.ij in.sql > jcc.out 2>&1
> ----------
> java -Dij.database='jdbc:derby://localhost:1527/wombat2;create=true' -Dij.protocol=jdbc:derby://localhost:1527/ -Dij.driver=org.apache.derby.jdbc.ClientDriver -Dij.user=APP -Dij.password=APP org.apache.derby.tools.ij in.sql > client.out 2>&1
> ----------
> in.sql contains:
> ----------
> drop table a;
> create table a (a int);
> insert into a values (2342323423);
> disconnect;
> exit;
> ----------
> I'll attach a jar with the .out files and in.sql. This means that the out files are in EBCDIC, to read them, one needs to run them through native2ascii -encoding Cp1047.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Reopened: (DERBY-583) networkserver does not return error
message strings in native encoding to ij on zseries
Posted by "Andrew McIntyre (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-583?page=all ]
Andrew McIntyre reopened DERBY-583:
-----------------------------------
> networkserver does not return error message strings in native encoding to ij on zseries
> ---------------------------------------------------------------------------------------
>
> Key: DERBY-583
> URL: http://issues.apache.org/jira/browse/DERBY-583
> Project: Derby
> Type: Bug
> Components: Network Server
> Versions: 10.1.1.0
> Environment: OS/390 (zseries) 1.06, ibm 1.4.2 jre
> Reporter: Myrna van Lunteren
> Assignee: Sunitha Kambhampati
> Fix For: 10.1.3.0, 10.1.2.4
> Attachments: ijzrepro.jar
>
> When running ij on an OS/390 without specifying any encoding or locale properties, and starting network server without any locale properties, various error messages do not get converted into the native encoding.
> Thus the messages are unreadable and not helpful.
> The problem is not limited to ij, just easy to reproduce with ij.
> Some errors return readable message strings are returned with jcc, but not with derbyclient, for instance the test lang/forupdate.sql has this line in it:
> select i from t1, t2 for update;
> which on linux & windows results in an error message 42Y90, "FOR UPDATE is not permitted in this type of statement." On OS/390 this error message is readable with jcc, but with derbyclient, only the string 'ERROR' is readable. Other messages - especially those with indirection in it like error 42X04 are equally unreadable with both clients.
> To reproduce 1 situation:
> - start networkserver
> - in another shell window, use the following string to run the in.sql file & save the output for jcc-client and derbyclient respectively:
> ----------
> java -Dij.database='jdbc:derby:net://localhost:1527/wombat3;create=true' -Dij.retrieveMessagesFromServerOnGetMessage=true -Dij.protocol=jdbc:derby:net://localhost:1527/ -Dij.driver=com.ibm.db2.jcc.DB2Driver -Dij.user=APP -Dij.password=APP org.apache.derby.tools.ij in.sql > jcc.out 2>&1
> ----------
> java -Dij.database='jdbc:derby://localhost:1527/wombat2;create=true' -Dij.protocol=jdbc:derby://localhost:1527/ -Dij.driver=org.apache.derby.jdbc.ClientDriver -Dij.user=APP -Dij.password=APP org.apache.derby.tools.ij in.sql > client.out 2>&1
> ----------
> in.sql contains:
> ----------
> drop table a;
> create table a (a int);
> insert into a values (2342323423);
> disconnect;
> exit;
> ----------
> I'll attach a jar with the .out files and in.sql. This means that the out files are in EBCDIC, to read them, one needs to run them through native2ascii -encoding Cp1047.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-583) networkserver does not return error
message strings in native encoding to ij on zseries
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-583?page=all ]
Kathey Marsden reassigned DERBY-583:
------------------------------------
Assign To: Kathey Marsden
> networkserver does not return error message strings in native encoding to ij on zseries
> ---------------------------------------------------------------------------------------
>
> Key: DERBY-583
> URL: http://issues.apache.org/jira/browse/DERBY-583
> Project: Derby
> Type: Bug
> Components: Network Server
> Versions: 10.1.1.0
> Environment: OS/390 (zseries) 1.06, ibm 1.4.2 jre
> Reporter: Myrna van Lunteren
> Assignee: Kathey Marsden
> Fix For: 10.2.0.0
> Attachments: ijzrepro.jar
>
> When running ij on an OS/390 without specifying any encoding or locale properties, and starting network server without any locale properties, various error messages do not get converted into the native encoding.
> Thus the messages are unreadable and not helpful.
> The problem is not limited to ij, just easy to reproduce with ij.
> Some errors return readable message strings are returned with jcc, but not with derbyclient, for instance the test lang/forupdate.sql has this line in it:
> select i from t1, t2 for update;
> which on linux & windows results in an error message 42Y90, "FOR UPDATE is not permitted in this type of statement." On OS/390 this error message is readable with jcc, but with derbyclient, only the string 'ERROR' is readable. Other messages - especially those with indirection in it like error 42X04 are equally unreadable with both clients.
> To reproduce 1 situation:
> - start networkserver
> - in another shell window, use the following string to run the in.sql file & save the output for jcc-client and derbyclient respectively:
> ----------
> java -Dij.database='jdbc:derby:net://localhost:1527/wombat3;create=true' -Dij.retrieveMessagesFromServerOnGetMessage=true -Dij.protocol=jdbc:derby:net://localhost:1527/ -Dij.driver=com.ibm.db2.jcc.DB2Driver -Dij.user=APP -Dij.password=APP org.apache.derby.tools.ij in.sql > jcc.out 2>&1
> ----------
> java -Dij.database='jdbc:derby://localhost:1527/wombat2;create=true' -Dij.protocol=jdbc:derby://localhost:1527/ -Dij.driver=org.apache.derby.jdbc.ClientDriver -Dij.user=APP -Dij.password=APP org.apache.derby.tools.ij in.sql > client.out 2>&1
> ----------
> in.sql contains:
> ----------
> drop table a;
> create table a (a int);
> insert into a values (2342323423);
> disconnect;
> exit;
> ----------
> I'll attach a jar with the .out files and in.sql. This means that the out files are in EBCDIC, to read them, one needs to run them through native2ascii -encoding Cp1047.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-583) networkserver does not return error
message strings in native encoding to ij on zseries
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-583?page=all ]
Kathey Marsden reassigned DERBY-583:
------------------------------------
Assign To: (was: Kathey Marsden)
Side tracked on xa issues for a little while so unassigning myself
> networkserver does not return error message strings in native encoding to ij on zseries
> ---------------------------------------------------------------------------------------
>
> Key: DERBY-583
> URL: http://issues.apache.org/jira/browse/DERBY-583
> Project: Derby
> Type: Bug
> Components: Network Server
> Versions: 10.1.1.0
> Environment: OS/390 (zseries) 1.06, ibm 1.4.2 jre
> Reporter: Myrna van Lunteren
> Fix For: 10.2.0.0
> Attachments: ijzrepro.jar
>
> When running ij on an OS/390 without specifying any encoding or locale properties, and starting network server without any locale properties, various error messages do not get converted into the native encoding.
> Thus the messages are unreadable and not helpful.
> The problem is not limited to ij, just easy to reproduce with ij.
> Some errors return readable message strings are returned with jcc, but not with derbyclient, for instance the test lang/forupdate.sql has this line in it:
> select i from t1, t2 for update;
> which on linux & windows results in an error message 42Y90, "FOR UPDATE is not permitted in this type of statement." On OS/390 this error message is readable with jcc, but with derbyclient, only the string 'ERROR' is readable. Other messages - especially those with indirection in it like error 42X04 are equally unreadable with both clients.
> To reproduce 1 situation:
> - start networkserver
> - in another shell window, use the following string to run the in.sql file & save the output for jcc-client and derbyclient respectively:
> ----------
> java -Dij.database='jdbc:derby:net://localhost:1527/wombat3;create=true' -Dij.retrieveMessagesFromServerOnGetMessage=true -Dij.protocol=jdbc:derby:net://localhost:1527/ -Dij.driver=com.ibm.db2.jcc.DB2Driver -Dij.user=APP -Dij.password=APP org.apache.derby.tools.ij in.sql > jcc.out 2>&1
> ----------
> java -Dij.database='jdbc:derby://localhost:1527/wombat2;create=true' -Dij.protocol=jdbc:derby://localhost:1527/ -Dij.driver=org.apache.derby.jdbc.ClientDriver -Dij.user=APP -Dij.password=APP org.apache.derby.tools.ij in.sql > client.out 2>&1
> ----------
> in.sql contains:
> ----------
> drop table a;
> create table a (a int);
> insert into a values (2342323423);
> disconnect;
> exit;
> ----------
> I'll attach a jar with the .out files and in.sql. This means that the out files are in EBCDIC, to read them, one needs to run them through native2ascii -encoding Cp1047.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-583) networkserver does not return error
message strings in native encoding to ij on zseries
Posted by "Myrna van Lunteren (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-583?page=all ]
Myrna van Lunteren closed DERBY-583:
------------------------------------
Fix Version: 10.1.2.4
(was: 10.2.0.0)
Resolution: Fixed
Assign To: Sunitha Kambhampati
> networkserver does not return error message strings in native encoding to ij on zseries
> ---------------------------------------------------------------------------------------
>
> Key: DERBY-583
> URL: http://issues.apache.org/jira/browse/DERBY-583
> Project: Derby
> Type: Bug
> Components: Network Server
> Versions: 10.1.1.0
> Environment: OS/390 (zseries) 1.06, ibm 1.4.2 jre
> Reporter: Myrna van Lunteren
> Assignee: Sunitha Kambhampati
> Fix For: 10.1.2.4
> Attachments: ijzrepro.jar
>
> When running ij on an OS/390 without specifying any encoding or locale properties, and starting network server without any locale properties, various error messages do not get converted into the native encoding.
> Thus the messages are unreadable and not helpful.
> The problem is not limited to ij, just easy to reproduce with ij.
> Some errors return readable message strings are returned with jcc, but not with derbyclient, for instance the test lang/forupdate.sql has this line in it:
> select i from t1, t2 for update;
> which on linux & windows results in an error message 42Y90, "FOR UPDATE is not permitted in this type of statement." On OS/390 this error message is readable with jcc, but with derbyclient, only the string 'ERROR' is readable. Other messages - especially those with indirection in it like error 42X04 are equally unreadable with both clients.
> To reproduce 1 situation:
> - start networkserver
> - in another shell window, use the following string to run the in.sql file & save the output for jcc-client and derbyclient respectively:
> ----------
> java -Dij.database='jdbc:derby:net://localhost:1527/wombat3;create=true' -Dij.retrieveMessagesFromServerOnGetMessage=true -Dij.protocol=jdbc:derby:net://localhost:1527/ -Dij.driver=com.ibm.db2.jcc.DB2Driver -Dij.user=APP -Dij.password=APP org.apache.derby.tools.ij in.sql > jcc.out 2>&1
> ----------
> java -Dij.database='jdbc:derby://localhost:1527/wombat2;create=true' -Dij.protocol=jdbc:derby://localhost:1527/ -Dij.driver=org.apache.derby.jdbc.ClientDriver -Dij.user=APP -Dij.password=APP org.apache.derby.tools.ij in.sql > client.out 2>&1
> ----------
> in.sql contains:
> ----------
> drop table a;
> create table a (a int);
> insert into a values (2342323423);
> disconnect;
> exit;
> ----------
> I'll attach a jar with the .out files and in.sql. This means that the out files are in EBCDIC, to read them, one needs to run them through native2ascii -encoding Cp1047.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-583) networkserver does not return error
message strings in native encoding to ij on zseries
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-583?page=comments#action_12373953 ]
Kathey Marsden commented on DERBY-583:
--------------------------------------
Probably the easiest way to reproduce this issue on Windows is to run this test with the derbyTesting.encoding property.
Here you can see the message is garbled. I am not sure if there are other encoding issues with the test but at least we will be able to see the message to find out.
D>java -Dframework=DerbyNetClient -DderbyTesting.encoding=UTF-16 org.apache.derbyTesting.functionTests.harness.RunTest lang/ConcurrentImplicitCreateSchema.java
*** Start: ConcurrentImplicitCreateSchema jdk1.5.0_02 DerbyNetClient 2006-04-10 17:36:35 ***
Initialize for framework: DerbyNetClient
java -Dderby.system.home=D:\testout\DerbyNetClient\ConcurrentImplicitCreateSchema -Djava.security.manager -Djava.security.policy=D:\testout\derby_tests.policy -DderbyTesting.codeclasses=file:/D:/p4/ma
rsden_derby/classes/ -DderbyTesting.codedir=D:\p4\marsden_derby\classes -DderbyTesting.serverhost=localhost -DderbyTesting.clienthost=localhost -DderbyTesting.codejar=file://unused/ org.apache.derby.d
rda.NetworkServerControl start
Attempt to shutdown framework: DerbyNetClient
2 del
< Closed connection
3 del
< Test ConcurrentImplicitCreateSchema PASSED
3 add
> java.sql.SQLException: ????????? :
> Caused by: org.apache.derby.client.am.SqlException: ????????? :
> ... 2 more
> exception thrown:
> java.sql.SQLException: ????????? :
> Test ConcurrentImplicitCreateSchema FAILED
Test Failed.
*** End: ConcurrentImplicitCreateSchema jdk1.5.0_02 DerbyNetClient 2006-04-10 17:38:43 ***
D>
> networkserver does not return error message strings in native encoding to ij on zseries
> ---------------------------------------------------------------------------------------
>
> Key: DERBY-583
> URL: http://issues.apache.org/jira/browse/DERBY-583
> Project: Derby
> Type: Bug
> Components: Network Server
> Versions: 10.1.1.0
> Environment: OS/390 (zseries) 1.06, ibm 1.4.2 jre
> Reporter: Myrna van Lunteren
> Fix For: 10.2.0.0
> Attachments: ijzrepro.jar
>
> When running ij on an OS/390 without specifying any encoding or locale properties, and starting network server without any locale properties, various error messages do not get converted into the native encoding.
> Thus the messages are unreadable and not helpful.
> The problem is not limited to ij, just easy to reproduce with ij.
> Some errors return readable message strings are returned with jcc, but not with derbyclient, for instance the test lang/forupdate.sql has this line in it:
> select i from t1, t2 for update;
> which on linux & windows results in an error message 42Y90, "FOR UPDATE is not permitted in this type of statement." On OS/390 this error message is readable with jcc, but with derbyclient, only the string 'ERROR' is readable. Other messages - especially those with indirection in it like error 42X04 are equally unreadable with both clients.
> To reproduce 1 situation:
> - start networkserver
> - in another shell window, use the following string to run the in.sql file & save the output for jcc-client and derbyclient respectively:
> ----------
> java -Dij.database='jdbc:derby:net://localhost:1527/wombat3;create=true' -Dij.retrieveMessagesFromServerOnGetMessage=true -Dij.protocol=jdbc:derby:net://localhost:1527/ -Dij.driver=com.ibm.db2.jcc.DB2Driver -Dij.user=APP -Dij.password=APP org.apache.derby.tools.ij in.sql > jcc.out 2>&1
> ----------
> java -Dij.database='jdbc:derby://localhost:1527/wombat2;create=true' -Dij.protocol=jdbc:derby://localhost:1527/ -Dij.driver=org.apache.derby.jdbc.ClientDriver -Dij.user=APP -Dij.password=APP org.apache.derby.tools.ij in.sql > client.out 2>&1
> ----------
> in.sql contains:
> ----------
> drop table a;
> create table a (a int);
> insert into a values (2342323423);
> disconnect;
> exit;
> ----------
> I'll attach a jar with the .out files and in.sql. This means that the out files are in EBCDIC, to read them, one needs to run them through native2ascii -encoding Cp1047.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-583) networkserver does not return error
message strings in native encoding to ij on zseries
Posted by "Andrew McIntyre (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-583?page=all ]
Andrew McIntyre closed DERBY-583:
---------------------------------
Fix Version: 10.1.3.0
Resolution: Fixed
> networkserver does not return error message strings in native encoding to ij on zseries
> ---------------------------------------------------------------------------------------
>
> Key: DERBY-583
> URL: http://issues.apache.org/jira/browse/DERBY-583
> Project: Derby
> Type: Bug
> Components: Network Server
> Versions: 10.1.1.0
> Environment: OS/390 (zseries) 1.06, ibm 1.4.2 jre
> Reporter: Myrna van Lunteren
> Assignee: Sunitha Kambhampati
> Fix For: 10.1.3.0, 10.1.2.4
> Attachments: ijzrepro.jar
>
> When running ij on an OS/390 without specifying any encoding or locale properties, and starting network server without any locale properties, various error messages do not get converted into the native encoding.
> Thus the messages are unreadable and not helpful.
> The problem is not limited to ij, just easy to reproduce with ij.
> Some errors return readable message strings are returned with jcc, but not with derbyclient, for instance the test lang/forupdate.sql has this line in it:
> select i from t1, t2 for update;
> which on linux & windows results in an error message 42Y90, "FOR UPDATE is not permitted in this type of statement." On OS/390 this error message is readable with jcc, but with derbyclient, only the string 'ERROR' is readable. Other messages - especially those with indirection in it like error 42X04 are equally unreadable with both clients.
> To reproduce 1 situation:
> - start networkserver
> - in another shell window, use the following string to run the in.sql file & save the output for jcc-client and derbyclient respectively:
> ----------
> java -Dij.database='jdbc:derby:net://localhost:1527/wombat3;create=true' -Dij.retrieveMessagesFromServerOnGetMessage=true -Dij.protocol=jdbc:derby:net://localhost:1527/ -Dij.driver=com.ibm.db2.jcc.DB2Driver -Dij.user=APP -Dij.password=APP org.apache.derby.tools.ij in.sql > jcc.out 2>&1
> ----------
> java -Dij.database='jdbc:derby://localhost:1527/wombat2;create=true' -Dij.protocol=jdbc:derby://localhost:1527/ -Dij.driver=org.apache.derby.jdbc.ClientDriver -Dij.user=APP -Dij.password=APP org.apache.derby.tools.ij in.sql > client.out 2>&1
> ----------
> in.sql contains:
> ----------
> drop table a;
> create table a (a int);
> insert into a values (2342323423);
> disconnect;
> exit;
> ----------
> I'll attach a jar with the .out files and in.sql. This means that the out files are in EBCDIC, to read them, one needs to run them through native2ascii -encoding Cp1047.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-583) networkserver does not return error
message strings in native encoding to ij on zseries
Posted by "Mike Matrigali (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-583?page=all ]
Mike Matrigali updated DERBY-583:
---------------------------------
Component: Network Server
> networkserver does not return error message strings in native encoding to ij on zseries
> ---------------------------------------------------------------------------------------
>
> Key: DERBY-583
> URL: http://issues.apache.org/jira/browse/DERBY-583
> Project: Derby
> Type: Bug
> Components: Network Server
> Versions: 10.1.1.0
> Environment: OS/390 (zseries) 1.06, ibm 1.4.2 jre
> Reporter: Myrna van Lunteren
> Fix For: 10.2.0.0
> Attachments: ijzrepro.jar
>
> When running ij on an OS/390 without specifying any encoding or locale properties, and starting network server without any locale properties, various error messages do not get converted into the native encoding.
> Thus the messages are unreadable and not helpful.
> The problem is not limited to ij, just easy to reproduce with ij.
> Some errors return readable message strings are returned with jcc, but not with derbyclient, for instance the test lang/forupdate.sql has this line in it:
> select i from t1, t2 for update;
> which on linux & windows results in an error message 42Y90, "FOR UPDATE is not permitted in this type of statement." On OS/390 this error message is readable with jcc, but with derbyclient, only the string 'ERROR' is readable. Other messages - especially those with indirection in it like error 42X04 are equally unreadable with both clients.
> To reproduce 1 situation:
> - start networkserver
> - in another shell window, use the following string to run the in.sql file & save the output for jcc-client and derbyclient respectively:
> ----------
> java -Dij.database='jdbc:derby:net://localhost:1527/wombat3;create=true' -Dij.retrieveMessagesFromServerOnGetMessage=true -Dij.protocol=jdbc:derby:net://localhost:1527/ -Dij.driver=com.ibm.db2.jcc.DB2Driver -Dij.user=APP -Dij.password=APP org.apache.derby.tools.ij in.sql > jcc.out 2>&1
> ----------
> java -Dij.database='jdbc:derby://localhost:1527/wombat2;create=true' -Dij.protocol=jdbc:derby://localhost:1527/ -Dij.driver=org.apache.derby.jdbc.ClientDriver -Dij.user=APP -Dij.password=APP org.apache.derby.tools.ij in.sql > client.out 2>&1
> ----------
> in.sql contains:
> ----------
> drop table a;
> create table a (a int);
> insert into a values (2342323423);
> disconnect;
> exit;
> ----------
> I'll attach a jar with the .out files and in.sql. This means that the out files are in EBCDIC, to read them, one needs to run them through native2ascii -encoding Cp1047.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira