DSXchange

DataStage is the perfect tool to do this. One approach is to check lengths in a transform stage and if the length is incorrect direct it out to an error link otherwise to pass it on. Have you tried this approach?

The appropriate question is not why it doesn't work in PX jobs but why it works (when it shouldn't) in Server jobs.

If the %CPU use on the DataStage system during job run is not above 80% then your job is not CPU bound, but most likely I/O bound.

[ is a WFF.

The server job is tolerant of this incorrect data format.

DST - this is not a bug. Embedded quotes must be doubled.

What Ray has suggested is rather complex and involved; one must know c++ to program the encryption and also be able to bind that into a buildop in DataStage. In your case this would be quite a lot of work and not recommended; so the appropriate answer to your question would be "no, a single col...

And if you post the complete error message someone here might be able to comment on it.

I think that you haven't received an answer to this question because the problem is not a DataStage one. If you were to use the command line interface to sendmail you would get the same error message, and it needs to be fixed by editing the mail configuration on the DataStage server machine.

dnat - your source file is badly formed, the correct thing to do is to correct the file. If that is not possible then another option would work if you are certain that your column separator, the '|' symbol, does not occur in the data. In that case, don't use a quote character at all and read in the ...

xmeta for log storage is only an option at 8.1, not before. I can't recall what the setting is to redirect logs, but chances are you don't have this turned on. In the project directory, do a "ls -al RT_LOG*" and see what the access rights are and if your datastage user has read and write a...

The value of either EquipmentTypeAssociatedId or EquipmentTypeId is not a valid number at runtime. Since Server does not enforce data types this is quite possible.

Are you reading sequential files or DB2 tables? I ask because DB2 does not have zoned decimal, whereas COBOL structures in sequential files do.

Don't rely on implicit conversions, do an explicit conversion so that the join key is identically defined in the left and right sources. Then see if you still have problems.

I think I like the idea of using an explicit sort stage as it gives the designer more control (i.e. limiting the sort memory, choosing the type of sort) but with unsorted data that needs repartitioning there is, as you've said, no real difference.

You will need to convert the number to a string. A simple way would be to declare a VarChar(8) field and the derivatio of