I'm not familiar with db2/iSeries, however I'm working on allowing characters from multiple languages to be stored in a db2 table. Are there any obvious issues with changing a column in a db2/iSeries table from a CCSID of 37 to 1208? How will switching the CCSID affect the data already stored in the column?
0
votes
1 Answers
0
votes
You'll see some scary messages:
CREATE TABLE QTEMP/TEST (FLD1 CHAR (10 ) CCSID 37 NOT NULL WITH DEFAULT)
ALTER TABLE QTEMP/TEST ALTER COLUMN FLD1 SET DATA TYPE CHARACTER (
10) CCSID 1208 NOT NULL WITH DEFAULT
CPD32CC - Change to field FLD1 may result in data loss.
--reason code 02: 02 - The new length is shorter than the current length.
CPA32B2 - Change of file TEST may cause data to be lost. (C I)
SQL0460 - Truncation of data may have occurred for ALTER TABLE of TEST in QTEMP.
But assuming the data is alpha, you shouldn't lose anything.
However, trying to store a 10-character string that requires DBCS encoding will fail as the column length is still only 10 bytes...and you'd need 22 bytes for a 10 character DBSC string in CCSID 1208. (Although the messages about truncation don't go away unless you increase the length to 28?)
If you change the type to NCHAR, which uses UTF-16 (CCSID 1200), the system automatically recognizes 10 as a character length and allocates 20 bytes to store it.
ALTER TABLE QTEMP/TEST ALTER COLUMN FLD1 SET DATA TYPE NCHAR(10) NOT NULL WITH DEFAULT
That being said, assuming your file is part of an existing application, changing the table is just the start of your problems.
Existing RPG programs would have to be recompiled and very likely modified.
You may be able to get around that requirement by uses a LF (view) layer that converts from Unicode to EBCDIC. That helps with current data. But doesn't help with new data that actually needs unicode.
Also, the older 5250 emulator that's include in IBM iAccess for Windows doesn't support unicode. You'd need to use the newer Access Client Solution (ACS) emulator or the browser based IBM iAccess for Web.
