DSXchange

Which database are you using? If you specify the correct code page for the database in question within DataStage you shouldn't be getting mapping errors. What is your database character set? What is the character set of your input/output data not in the database? What character set is triggering you...

The basic functionality is present in the product to do this using the generic stage, here a parameter value may be used to specify upon which column one is to re-partition on.

Nonetheless it would be a lot easier if one could specify the column as a parameter value within the Designer GUI.

Usually the log files will contain error or warning messages.
Most likely cause is the mail configuration on the DataStage server.

I am fully aware of that, I am just looking at explaining this job's behaviour.

Hmm... I wonder how it truly works. Is your database primary key just the DIN column or are there other columns as part of the PK?

If you add the option "$APT_DISABLE_COMBINATION" and set to "true" in the original job does the error picture remain the same?

Can you make a copy of the job with just the source Oracle stage going to a PEEK and attempt calling that up to see if the problem remains reproduceable?
Also, does that Oracle stage contain SQL or even before/after code?

What is the job doing and if you monitor it:
- Has the job processed any data?
- If so, then has it process all of the expected data and then "hangs"?
- Does it use any CPU in the "hang" state?

Other questions would depend upon the answers to these.

Phil,

if the original DIN key had 10 records, and you only replace 4 of them, the remaining 6 should be unchanged (and thus incorrect for your implementation)

I wonder if you could remove these with a before-stage SQL to delete and commit, then an insert of the new records..

Try the hash on the first 1, 2 or 3 columns (must be identical for Left and Right links).

What do you mean by "mirrored" in this context with CDC?

As you had assumed, if you add a rule for one error message ID then all occurrences of that error are affected. The rule takes effect upon the next run.

Did you add a job message handler or a project level one? If you move job from one category to another then the job message handler is lost.

Yes, linux and UNIX are close enough that the uninstallation procedures are the same.

What column are you hashing on and what column(s) are you using for your join?

Is that SELECT statement in your stage, or do you have "select statement from file" and this select is in the file?