DSXchange

I have never used a buildop so cannot comment on that but I dont see why there will be a performance penalty. Build your C code, run it as a routine and buildop, do some benchmark tests. Let us know what you find

Depends upon what your comfortable with. I prefer C routines.

It generates it regardless. That option is just to get the OSH script for your viewing.

pavankvk wrote:Why is it trying to import from the sequential file when you are writing to it?

Thats only for view data.

Version control also compiles the job but that happens as it imports the job.

Welcome Aboard
Do an exact Search on key words "skew in the usage".
AND please post in the correct forum. In your case it will be IBM WebSphere DataStage Enterprise Edition.

You can mark this topic as Resolved too based on this.

Ahh...Cute...

PPID being 1 means its a zombie. Well cant your unix admin monitor whats going on and what process started as a result of which dbx was created ?

chulett wrote: What's the name of the source stage? QWERT?

How do you know that Craig

Do this. Sort the incoming data on your key. Define two stage variables in the transformer, say condFlag and prevVal. The will basically detect duplicates and flag them. Their both will be initialized to 0. Their derivation will be as follows: condFlag | if (prevVal <> src.key) then 'X' else...

Do this

Welcome Aboard
It has to be derived and fed to the surrogate key generator as a parameter. Click herefor a recent discussion on this topic.

Array size is different than transaction size. Specify transaction size to 1 so that it commits after passing every row. This way if the same id comes again, it will find the record commited and update it.
WHile your at it you might as well set the array size to 1 too and avoid that warning.

These decimal fields, are they signed. I mean, do you need to convert them to PicS9 or just comp3?