DSXchange

The purge settings are read when a job is run; thus your logs will remain until the next run. You can export all the jobs, delete them, then re-import them to clear all the log files if manually doing a "clear log" for each job is too much work.

Odd, as far as I know, the 3 environment variables NLS_LANG, LANG, and LC_ALL are ORACLE values and are not used by the DataStage server engine.

Could it be that the production server was not installed with NLS enabled? This would explain the missing character set definitions.

What happens if you test it without hardcoded parameter values, perhaps make a copy and manually type in the values - does it work then? If yes, then you can start to track back the error.

That is great news. Because of bureaucracy at my current site it will be weeks before I can get a valid support ID at IBM in order to do the same. It would be very nice if you could post the results here so that I can "piggyback". I've now had to manually go through many jobs and check all...

That is an interesting question that I haven't seen posed before, but unfortunately I think that the answer to your question will be that the only way to test checkpointing is to force errors into your tests.

There is nothing built into DataStage that does this. There are a number of freeware/public domain entries to be found for "convert integer to words c++" on Google, and the documentation shows how to create buildops and call them from DataStage.

What you are looking into doing is "historization" of data. Depending upon your rules it can be simple or quite complex. I have just implemented program code for doing exactly this - the specifications were over 50 pages long and peppered with terms such as "temporal irreducibility&qu...

The warning message isn't the problem, it occurs on Windows 8.1 installations and is, as far as I know, reported to support. After the first run of the job after a compile the warning won't occur again.

Search elsewhere for the hang condition.

That should tell you that the entries you are putting into your job aren't the ones that DB2 is getting.
How are you declaring the userid/password in the job?

Just to test that you are actually using the userid/password combination that you think, take another userid/password and use those as parameters to the database job. Is the error message the same or is it working?

AIX and micropartitioning perhaps?

I would increase the commit frequency, doing this every 2000 rows means you are doing 30000000/2000 = 15,000 commits. If your database has sufficient space, consider upping this number significantly. Just for comparison, how long does the job run if you replace the ODBC write stages with a PEEK or C...

Your select contains DML logic which turns "LEGACY_MEMBER_ID" from non-nullable to nullable.

Could it be that you are connecting to different databases in DataStage and from the command line? That is the simplest explanation. Could you also post the exact error message, please?

My point is that after the API stage inserts the data into the DB it will have the exact same value as with the bulk stage.