bethrmoore
commented
9 months ago I don't have IDZ so I have not reproduce it. Beth
Open bethrmoore opened 9 months ago
bethrmoore
commented
9 months ago I don't have IDZ so I have not reproduce it. Beth
FALLAI-Denis
commented
9 months ago Hi,
My analyse of the problem as end user.
The problem described here is not related to the Db2 for z/OS developer extension.
Working with spufi or COBOL program relate of ccsid options at precompile/compilation (association or not of a ccsid to host variable) and at bind (the package should have the same ccsid as db2 subsystem). If program / package / tablespace / db2 subsystem use the same ccsid no translation occurs : data in program are stored in db2 without any translation. Use case of spufi, and any tool acceded thru a 3270 terminal also depends of ccsid defined in 3270 terminal wich must be same as db2 subsystem.
IDz or any remote client use Db2 DRDA to access Db2 and these clients don't use EBCDIC ccsid. They probably use UTF8 ccsid or an ISO8859-x or Windows-xxxx (Windows-1252 for France). A ccsid translation occurs.
Ccsid 297 doesn't define Euro character code. Translation from UTF8 or other ascii ccsid can't resolve Euro character to ccsid 297, and I think should use a replacement code. To handle Euro character in db2 you should use 1147 ccsid everywhere: db2 subsystem, tablespace, bind, compilation, source encoding, 3270 terminal.
For COBOL compilation I recommand to use noccsid option : don't associate any ccsid to program host-variable (neutral).
Note that ccsid translation has CPU overhead.
I have PDF documents that detail the problem described here but I cannot add them to my publication (too big?). They no longer exist on Internet and I cannot provide any link. I can send them to personal email.
bethrmoore
commented
9 months ago @FALLAI-Denis Hi Denis, Yes, can you please send the doc to bethrm@us.ibm.com Thanks, Beth
FALLAI-Denis
commented
9 months ago Hi,
Documents sent.
Denis
Development environment where the bug occurred
java -versionand paste the details here):Problem description
Customer states: Table created with CCSID EBCDIC , and insert euro sign : insert into tivtest (code) values ('€');
-Spufi Insert with Euro sign OK , we have x'9F' in the table -Cobol insert OK , x'9F' in the table (precompil option is CODEPAGE(297) -Insert thru Idz , not OK
So the only thing that is blocking is the insert from remote. I verified the NULLID.* packages are bound with ENCODING_CCSID='297' I run the select encoing_cssid from sysibm.syspackage and 99,99% of our packages are "297".
Detailed steps for reproducing the problem:
Observed behavior
-
Expected behavior
-