DSXchange

http://www-01.ibm.com/support/docview.w ... wg21515617

or, better yet, Let me google that for you

Was that ASAP enough?

Usually such jobs are limited by I/O speed and not CPU, and in both cases the same amount of I/O is being done. Parsing the columns directly in the stage should be somewhat more efficient than doing using a field() function, so the results that Chandra has seen are what I would expect; the increase ...

I'd stick with analyzing your example (b), since that shows a big unexplained difference in speeds.

What are the sources to the lookup in that job? Database connections? If so, do a simple dummy job DB -> peek stage with a large volumn on both machines and compare the throughput.

Sura - I'm curious as to how you would solve this problem using a loop in the transform stage. Could you expand on your solution?

Then back to my request for the full error message.

Oh

In cases like this the only way to get a good answer is to cut-and-paste the entire error message, those two words "missing expression" aren't quite enough information.

And after you add the $INCLUDE, remember that the routine expects a Job Handle as the first parameter and your variable "seq_TMW_MID_INVENTORYHIST_ONHAND" looks suspiciously like a job name. You need to use DSAttachJob() to get a handle given a name.

Example (a) tells me that the new disk target for datasets is slower. Is it a SAN, or the same SAN and the same virtual disk?. Note that this test is only useful for comparison purposes if it runs for at least a minute, longer is better. Example (b) doesn't necessarily identify any specific bottlene...

What exactly is the error message you are getting (try cut-and-paste). What is your database output stage? There might be a way around the nullability issue.

What stage are you using and what is the exact message? You might be able to get by with nullable columns in this case.

What exactly is the error message you are getting. In some cases with nullability differences you can set default values, but in others the error is a "hard" one which cannot be circumvented. Dynamically handling any nullable columns in a generic job is a bit more complicated and would inv...

You don't need a schema file. The schema is embedded in the dataset and the columns are automatically used when RCP is turned on at this stage. Try a test job, declare your dataset and write to a peek stage, compile & run and ...voila... your columns are all visible in the peek.

If the names and datatypes for the datasets and their corresponding tables are identical then you have a perfect situation and the solution is very easy. You declare your source and target with RCP turned on and define no columns at all, datastage takes care of the rest. If columns are missing in th...

In both cases the job has no information about the previous run or state. The answer to the question depends upon how you read your input data and how you performed commits on the aborted job.