DSXchange

yes.

http://www-01.ibm.com/support/docview.w ... #linsystem

http://www-01.ibm.com/support/docview.w ... wg21315971

Explicity hash partition on "ID" as early in the job as possible and see if the result changes.

Ignore DataStage for a minute and concentrate on the different users and their access rights. Perhaps your DBA could ensure that their privileges are identical and then you could check to see if the problem persists. http://publib.boulder.ibm.com/infocenter/iisinfsv/v8r0/index.jsp?topic=/com.ibm.swg...

The 'gdb' and 'sed' part of the message can be ignored, it refers to the debugger and getting the stack and this message is common.

If you turn off operator combination ($APT_DISABLE_COMBINATION to "true") the error message might help a bit more.

You are trying to open too many dynamic (type 30) files at once. The solution is to modify your "uvconfig" file and raise the setting for the T30FILE parameter. What is your current value? The documentation describes the steps needed to make changes in the file active but they include stop...

Sorry Ed, I must have equated the userid with size Since you soaked up all my knowledge, can I have some of it back please? A couple of hit-points would do me well right now.

Glad to hear that you've solved it, even though the solution was non-trivial.

<sigh> have you done the comparision of the schemas displayed when you set $OSH_PRINT_SCHEMAS?

Is your read a TABLE read or have you specified SQL for the SELECT?

I just realized that sometimes when jobs abort the schemas are not displayed. Try a test job with the output database stage replaced with a peek and see if the schemas from the source are different between the two user-ids. I'd wager that they are.

I'm going to stop posting on this thread, since I don't enjoy repeating myself again and again. Perhaps someone else might be able to assist. If you don't look at the schemas to determine where the varchar(0) comes from then you won't make much progress. Can both of your users do a "describe {t...

So now we come back to the internal schemas. See what the schema definitions coming out of your source in both the "good" and the "bad" scenarios.
Since the only difference is the user-id to Oracle, perhaps the one user doesn't have sufficient access rights to read the DDL.

You need to set this print schemas to "true" and it will create a log entry in the director log showing as "main_program: Schemas:" and containing the detailed schemas The column "NUMR_2EME_LIGN_ADRS_AFNR_V2:nullable string[0];" is certainly wrong. Where do you define i...

I am sorry but I cannot make heads or tails from your text-graphic, the forum software didn't preserve any formatting. "BLANK" as string contents is not a reserved word, and "BLANK" should be equal to "BLANK" as you assume. I suggest you add another output link to a pee...

This variable won't change the outcome. But it does add an entry to the log file which shows the schemas used for each link. Run the job with one user, store the schemas in a file. Run it again with the other user, store that schema in a file. Compare the two schemas for the output to see if there a...

Steve, if you turn on $OSH_PRINT_SCHEMAS can you check whether the column datatype going into your CFF stage in the "bad" environment is signed or not - that would narrow down the search for a cause.