View previous topic :: View next topic
|
Author |
Message |
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hi Rafael,
Good morning
Good idea asking about the custom translation table in a new topic - i looked around some last night, but did not find anything useful.
If a custom translation table does not happen, you should be able to do what you need with your sort product. . .
Quote: |
Which sort product is used on your system? If you are not sure, just run any sort and look at the sysout. |
|
|
Back to top |
|
|
Rafael Longo
New User
Joined: 21 Jul 2007 Posts: 33 Location: Campinas, S?o Paulo, Brazil
|
|
|
|
Thanks for all your time and help, Dick...
Once I find a solution, I shall get back to you on this...
Regards,
Rafael |
|
Back to top |
|
|
Rafael Longo
New User
Joined: 21 Jul 2007 Posts: 33 Location: Campinas, S?o Paulo, Brazil
|
|
|
|
Hello,
Looks like EBCDIC's NL (0x15) do not have a ASCII equivalent. Teradata SQL Assistant client (which I run from windows) translates the 0x15 to 0xD5 (Don't ask me why this conversion was chosen).
So, the problem occurs only when I issue the query through windows. When I issue it from Mainframe (Green-screen, right Dick? ), I get the 0x15's back (I know I said that I got the D5's from mainframe too, but I did something wrong before...).
The thing is that I changed the "Session character set" from ASCII to UTF8 in the ODBC driver that Teradata SQL assistant uses to log and the the 0xD5's started to display correctly... as a Line wrapping.
So, it looks that the issue was just a diplaying problem on the particular client that I was using on windows...
And my problem is solved! The binary upload and conversion through OCOPY did it...
Thanks guys. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Cool
Good to hear it is working. |
|
Back to top |
|
|
|