DSXchange

(Auto) will apply hash partitioning to the join key fields on both inputs and insert a tsort operator (and probably a parallel buffer operator) on both inputs. All this can be seen in the score.

You have an inner join with Drop, a left outer join with Continue.

The zeroes are coming from your job design. 0 can arise from a logical expression; it is used to represent False in DataStage. So if your derivation expressions have been constructed as assignment statements, which is not correct, then you would usually expect to see zeroes. I heartily endorse the e...

A small spot of empire building...

With more DataStage knowledge you'd appreciate that your question HAS been answered. And on a weekend, what's more. How much would THAT cost from your support provider?!! +---> Table XXX (constraint TABLE_CODE = "XXX") -------> Transformer +---> Table YYY (constraint TABLE_CODE...

Try it with this value, and post your response.

It is NOT the same result as Convert().

Welcome aboard.

You posted this question in the incorrect forum. This forum is for server jobs. There is a separate forum for parallel jobs.

Import errors occur when reading, rather than writing. Figure out how the data you're reading don't match the metadata you have designed in.

The constraint in the Transformer is applied in the Constraints grid. Choose the second tool from the left in the toolbar.
The constraint expression itself is a true/false for each output link, for example

DataStage is a 32-bit application. The highest address you can access in any one memory space with a signed 32-bit integer is, curiously enough, 2GB.

To address more memory than that requires some fairly fancy coding.

But, then, why should it grab more than it needs?

Well, you know what to trap and post next time it occurs.

Get a UNIX shell such as MKS Tookit or CygWin. Lots of lovely tools there, even cat works better than the DOS type command, especially in terms of scaling.

No. Routine code is stored separately from job/sequence code. Can you reliably produce incorrect results in test mode? What other things are happening on the server when you can? In particular, might any other process be using this routine? Please advise what test data gave incorrect results. Double...

There's no easy way. You just have to do it. Take short breaks occasionally. Save your work periodically so you can exit without saving if it all goes pear shaped at some point.

Look in the log to see what command was actually executed - were any quotes stripped from it, for example? You may need to escape the quotes.

Contemplate using instead of - it will consume far fewer resources.

If the server is Windows ODBC should be fine with it, so long as the DSN points to the correct location.