Perhaps the character is being translated incorrectly from DB2 to DataStage. Isolate the characte and use the SEQ() function to determine which ASCII value arrives in DataStage.
ArndW wrote:Perhaps the character is being translated incorrectly from DB2 to DataStage. Isolate the characte and use the SEQ() function to determine which ASCII value arrives in DataStage. ...
Change your select to only get rows that have the character in that column. Then find out which position the character is in, i.e. 8, then output SEQ(Input.Column[8,1]) to get the ASCII value as the DataStage job sees it.
ArndW wrote:Change your select to only get rows that have the character in that column. Then find out which position the character is in, i.e. 8, then output SEQ(Input.Column[8,1]) to get the ASCII value as the DataStage job sees it.
What is the character set of your source database, or source table? You need to tell DataStage this value on order for the DB2 read stage to work correctly
ArndW wrote:What is the character set of your source database, or source table? You need to tell DataStage this value on order for the DB2 read stage to work correctly ...
it is 37
I created another table and made it 284, no changes
both times comming as 35
Also, I am usning ODBC stage, sorry forgot to tell
ArndW wrote:What character sets do those numbers refer to? ...
Well, I finaly found a solution:
In ODBC stage I and using Replace function to replcace "wrong" hex value and the converting all to graphic. Not very pleasant but works just fine:
Cast(Replace( F.ABALPH, x'7B',x'69') as graphic (40) ccsid 13488)