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.
Bug
Closed
Major
networkserver does not return error message strings in native encoding to ij on zseries
