DSXchange

NLS will be of no help whatsoever. This is an exercise in time zones, not locales. You need to establish the time zone (TZ environment variable) on the server and perform time arithmetic (and perhaps string manipulation) to produce a UTC time.

Can you set up a "bucket" table of the keys in your stream source and do the lookups against a view made up of the inner join between that and the full table?

What did you get when you imported the table definition from Oracle using the same stage type that you are using in the job (for example the plug-in stage)? Use that data type in your job design.

That sqlldr will always be fastest. DataStage can prepare ctl and dat files for sqlldr, and you may get gains from that part of the process compared with what you're currently doing, and DataStage can control the execution of sqlldr, but your client's expectations need better management.

Does the RDBMS stage allow you to include a WHERE clause?

No

Why do you want to do something like that?!!!

... though computationally intensive.

The dsjob command retrieves job log information from the job log, which is a separate table for each job in the Repository database. The job is not executed when the log options are used with the dsjob command.

No it isn't. Something you are doing downstream of the transformer stage is converting the true null to the representation "NULL" - probably a null field value, my guess is in a Sequential File stage's input link metadata.

IS there a SetNull() function in a server job Transformer stage?

None. It works fine for me.

Tough.

Create a stage variable containing a list of them. Initialize it only; you don't need to re-derive for every row processed.

No. There is a DB2z stage in version 8.1 (not version 8.0), but it is only for accessing DB2 on the zSeries machine.

Alas, that is not valid. A parameter reference can not be a function call.