DSXchange

Can you try using an ODBC stage instead of OLEDB ? Make sure you have defined a System DSN (DataStage does not work with User DSNs). You may receive a less abstruse error message.

No, you can inspect your logic looking for likely candidates to cause an arithmetic overflow (usually multiplication, but maybe also addition (aggregation) over many values). Also look at the source data for numeric columns that contain large values. No need to "try" the job.

Duplicate the invocation ID in a job parameter and test that value.

ALLOWNFS must be 1. Just changing it is not enough, you also need to run the uvregen utility.

Can you effect this COPY using a CMD shell? What is the value of %ERRORLEVEL% after the command?

Alternately use the -exec option with find command.

TimestampToDate() won't help - it goes the wrong way. Do you really need a Timestamp data type, or do you need a string formatted like a timestamp?

You still wouldn't be a premium member, so probably not.

Premium membership is not expensive (under Rs12 per day) and it's the main source of revenue to keep DSXchange alive and well.

Whatever you do - even if it's running a generic job 600 times - will eat up resources. There's no way around that.

First thing to do is to look for some columns with large numbers in them, or columns that derive from multiplication somewhere in the job design.

Enclose deviant column names in double quote characters, for example "PRICE/COST RATIO"

Depending on the stage type you are using, you may also be able to use the Enable Quoted Identifiers property.

Is it possible for you to use parallel job? If so there may be easier methods involving Runtime Column Propagation and change detection stage types. You may be able to create just one job.

There is no schema for the reject link. You get one raw string. It can be re-parsed, if necessary, perhaps using a Column Import or Transformer stage.

Use the correct UniChar() function to describe the characters.

That IS my suggestion.