Hi
Change your datatype from string to ustring in your schema file .
This change might solve your issue.
Thanks
Venki
Invalid character(s) ([xFC]) found converting string
Moderators: chulett, rschirm, roy
Thanks for the suggestion Venki, but it won't work in our case.
I forgot to explain the job design.
Job1: Reads the given db2 table using RCP, and writes it to a dataset (e.g. <tablename>.ds
Job2: Reads this dataset, with the columns explictly defined (as ustring).
So we have no opportunity to change the data type in the schema file.
As a workaround, we redefined the problem column in DB2 as Vargraphic. RCP interprets this as ustring[], avoiding the warning.
John Wyman (one of the brilliant guys from IBM Tech Support) has given me a few ideas to try when I get the chance. So stay tuned.
I forgot to explain the job design.
Job1: Reads the given db2 table using RCP, and writes it to a dataset (e.g. <tablename>.ds
Job2: Reads this dataset, with the columns explictly defined (as ustring).
So we have no opportunity to change the data type in the schema file.
As a workaround, we redefined the problem column in DB2 as Vargraphic. RCP interprets this as ustring[], avoiding the warning.
John Wyman (one of the brilliant guys from IBM Tech Support) has given me a few ideas to try when I get the chance. So stay tuned.
The fix was to add a User Variable to the project: DB2CODEPAGE
and assign it the value: 1208
Some of John's wisdom:
and assign it the value: 1208
Some of John's wisdom:
This [encoding] is decided not by DataStage but by the client software in between DataStage and the the Server database, with DB2 it is DB2CODEPAGE or your default locale, with Oracle it is NLS_LANG and ODBC it is IANAAppcodePage in .odbc.ini. How the client software decides this and what defaults are taken vary slightly. Historically client software was not Unicode enabled and relied for display on a specific character set, even if the database server was capable of holding the data in a Universal Character set such as UTF-8 or UTF-16, it would be converted depending on the clients requirements. You implicitly told DB2 to present to you in iso-8859-1 because this is the locale of your server (DB2CODEPAGE not being set, it looks at that first).