On 2023-08-28 11:34 a.m., Birgitta Hauser wrote:
IMHO the best way is to convert the character columns (in your tables or physical files) from EBCDIC to either UTF-8 or UCS-2 or UTF-16.
... not a small project because you also have to modify (but at least recompile) your programs.
If the application has RPG program that are accessing database files
using native I/O (READ, CHAIN etc) , extra care may be needed in the RPG
program if the database file has UTF-8 fields.
(But UCS-2 and UTF-16 fields work fine in RPG. What I'm going to talk
about here only applies to UTF-8 fields.)
By default, when RPG does I/O to a database file, it assumes that all
alphanumeric data (CHAR or VARCHAR) is in the job CCSID. Database
handles this CCSID conversion between the data in the file and the I/O
buffers.
UTF-8 data is considered by RPG (and database) to be "alphanumeric".
There are two problems with this for UTF-8 data in database files
accessed by native I/O in RPG:
1. If the job CCSID is 65535, database doesn't do the conversion, but
RPG (by default) assumes that the conversion was done.
2. The UTF-8 data used by the current job should all be able to be
converted to the current job CCSID.
To handle UTF-8 data correctly for RPG native I/O, these keywords are
important:
CTL-OPT OPENOPT(*NOCVTDATA)
- default to avoid having database convert alphanumeric data to the job
CCSID for all database files
DCL-F DATA(*NOCVT)
- avoid having database convert alphanumeric data to the job CCSID for
this file
DCL-DS CCSID(*EXACT)
- define alphanumeric subfields with the same CCSID as the CCSID of the
field in the file
- without CCSID(*EXACT), RPG defines the subfields with the job CCSID
https://www.ibm.com/docs/en/i/7.5?topic=type-ccsid-conversions-during-input-output-operations
https://www.ibm.com/docs/en/i/7.5?topic=keyword-ccsidexact-noexact
Again, this is only an issue with UTF-8 data in database files. There is
no similar issue with UCS-2 and UTF-16 data in database files.
midrange.com
