DSXchange

I would still like to have an answer to the question about whether it always takes four hours or whether this was a one-off.

Perhaps the problem is arising when DataStage is querying the data source to determine the data type - the executing user lacks SELECT privilege on the system table in which column information is stored? Just an idea.

I did think of a real groaner of an answer - an extended pun on the word "itch" - but decided not to go with it.
(It involved ITCH as an acronym.)

The problem is at the 153rd character position. That should make it very easy to track down, using a utility such as a hex editor (or even an od -xc command).

The problem is at the 153rd character position. That should make it very easy to track down, using a utility such as a hex editor (or even an od -xc command).

Does the job refer to any other components, maybe shared container, routine, etc? If so, have those objects been imported too?

Multiple guess?

Use Filter command in Sequential File stage. The command sort -u #filepath# might be a good choice.

Have you set the PWD environment variable?

DataStage clients can ONLY be installed on Windows.

The limiting factor is probably, and curiously perhaps, the SELECT operation, which is performed sequentially. Under appropriate circumstances I have seen over 100,000 rows/second but, then, I believe this metric to be meaningless for most purposes.

The mere fact that you can import it does not mean that it will be accepted when the job is run.

Thanks, but the UniAccess ODBC driver can only be installed on Windows systems.

Our DataStage server is on AIX, so I'm looking for a UNIX-based driver.

I expect DataStage is objecting to the name "#tmp". In DataStage, the sharp sign introduces a reference to a job parameter. Some stage types allow a technique for "managing" this character (and the dollar character), others do not. Can you create a synonym for the table name, and...

Is this, perhaps, a multi-instance job with two (or more) instances running at the same time?