Dears,
In the DataStage Engine Server, when I run some jobs to split data using administrator user, it goes smoothly with no problems. But, when I run it using another user, even with administrative privileges, the Arabic characters comes as garbage.
Could you please investigate this Issue ... ?
Note:
the Source is : DB2 through ODBC(iSeries Access ODBC Driver).
the Target is : Text file .
DataStage Arabic Character Issue
Moderators: chulett, rschirm, roy
Re: DataStage Arabic Character Issue
Your source table(s) live on iSeries.waklook wrote:Dears,
In the DataStage Engine Server, when I run some jobs to split data using administrator user, it goes smoothly with no problems. But, when I run it using another user, even with administrative privileges, the Arabic characters comes as garbage.
Could you please investigate this Issue ... ?
Note:
the Source is : DB2 through ODBC(iSeries Access ODBC Driver).
the Target is : Text file .
Where does your target text file live - on the DataStage server (windows machine)?
So... with your Admin user sees good data, and with User2 (some other user), you see "garbage".
After you run the job as User2, what happens if you log in as Admin and view the target Text file - does it still have garbage? (if not, it might just be something with User2's localization settings).
DB/2 on AS/400 - hmm, same credentials (id/pw) for db-connection when User1 vs. User2 run the job?
Can the DB/2 admins tell you what your code page your source table on DB/2 is using?
Are you running with NLS enabled?
What are you using for NLS mappings on your DB/2 stage?
What are you using for NLS mappings on your target text file stage?
What happens if you change your NLS mappings to use UTF-8 everywhere?
note: I am a little surprised that it works well for the Admin user.
Note this part: this code page is not compatible with ISO 8859-6 and
MacArabic encodings. (from http://en.wikipedia.org/wiki/Windows-1256 )
Thanks for your feedback
Please see comments below :
Your source table(s) live on iSeries.
Where does your target text file live - on the DataStage server (windows machine)?
Yes, in Windows server machine.
-------
So... with your Admin user sees good data, and with User2 (some other user), you see "garbage".
After you run the job as User2, what happens if you log in as Admin and view the target Text file - does it still have garbage? (if not, it might just be something with User2's localization settings).
I see garbage data as well.
-------
DB/2 on AS/400 - hmm, same credentials (id/pw) for db-connection when User1 vs. User2 run the job?
Yes, same credentials used.
-------
Can the DB/2 admins tell you what your code page your source table on DB/2 is using?
EBCDIC 420
-------
Are you running with NLS enabled?
Yes
What are you using for NLS mappings on your DB/2 stage?
we are using ODBC stage, not db2 stage. And it is using the default NLS code (1252-CS)
What are you using for NLS mappings on your target text file stage?
Default (1252-CS)
What happens if you change your NLS mappings to use UTF-8 everywhere?
comes as weird characters (garbage).
Please see comments below :
Your source table(s) live on iSeries.
Where does your target text file live - on the DataStage server (windows machine)?
Yes, in Windows server machine.
-------
So... with your Admin user sees good data, and with User2 (some other user), you see "garbage".
After you run the job as User2, what happens if you log in as Admin and view the target Text file - does it still have garbage? (if not, it might just be something with User2's localization settings).
I see garbage data as well.
-------
DB/2 on AS/400 - hmm, same credentials (id/pw) for db-connection when User1 vs. User2 run the job?
Yes, same credentials used.
-------
Can the DB/2 admins tell you what your code page your source table on DB/2 is using?
EBCDIC 420
-------
Are you running with NLS enabled?
Yes
What are you using for NLS mappings on your DB/2 stage?
we are using ODBC stage, not db2 stage. And it is using the default NLS code (1252-CS)
What are you using for NLS mappings on your target text file stage?
Default (1252-CS)
What happens if you change your NLS mappings to use UTF-8 everywhere?
comes as weird characters (garbage).
drivers
There are some trouble shooting things we could do to dig into
the data values, but the more I think about this I am actually
surprised that it works with the Admin user but not the other user.
If the only difference is simply that Admin user works ok,
and other user doesn't work, then it has to be something
related to the windows machine where the drivers
are installed.
Let me know if these are true statements:
1) The datastage job works for the Admin user
2) nothing is changing in the DataStage job.
3) the same job generates garbage for another user
If those are true, then it must be something like a
.properties file in the particular user's home directory,
or a driver setting under HKEY_CURRENT_USER in the
windows registry.
You're using a Windows ODBC to a iseries DB2/400 table,
so what are you using for drivers on Windows?
DB2 Connect? Client-access? as400 toolkit? (that is the last
thing I used, but that was for doing java work a few years ago).
Other?
What happens when you view the data with Admin using
non-Datastage tools (e.g. whatever the driver installed with)?
I would expect the Admin user to see good data.
What happens when you view the data with the other user,
again using non-Datastage tools?
I would expect that user to need some driver-related tool setup.
Has the non-Admin user connected to the as400 and can that
other userid run SQL queries with good results?
note: I don't mean running SQL in a 400 terminal emulator,
but something like the db2 command line running on
Windows (at the risk of being obvious, the point is to exercise
the windows drivers, and view the results in windows).
Good luck. If something else is different, we can dig into
the actual character codes that are being retrieved from db2/400.
John G.
the data values, but the more I think about this I am actually
surprised that it works with the Admin user but not the other user.
If the only difference is simply that Admin user works ok,
and other user doesn't work, then it has to be something
related to the windows machine where the drivers
are installed.
Let me know if these are true statements:
1) The datastage job works for the Admin user
2) nothing is changing in the DataStage job.
3) the same job generates garbage for another user
If those are true, then it must be something like a
.properties file in the particular user's home directory,
or a driver setting under HKEY_CURRENT_USER in the
windows registry.
You're using a Windows ODBC to a iseries DB2/400 table,
so what are you using for drivers on Windows?
DB2 Connect? Client-access? as400 toolkit? (that is the last
thing I used, but that was for doing java work a few years ago).
Other?
What happens when you view the data with Admin using
non-Datastage tools (e.g. whatever the driver installed with)?
I would expect the Admin user to see good data.
What happens when you view the data with the other user,
again using non-Datastage tools?
I would expect that user to need some driver-related tool setup.
Has the non-Admin user connected to the as400 and can that
other userid run SQL queries with good results?
note: I don't mean running SQL in a 400 terminal emulator,
but something like the db2 command line running on
Windows (at the risk of being obvious, the point is to exercise
the windows drivers, and view the results in windows).
Good luck. If something else is different, we can dig into
the actual character codes that are being retrieved from db2/400.
John G.
