DSXchange

No worries. It was just the way the problem was formulated sounded very much like a typical open-ended interview question.

Yes, but you need to handle this in your transform. With DCOUNT(In.String,'~') you find out how many tilde you have, then with FIELD(In.String,'~',nnn) you can pick out field nnn from the string. The rest is up to you and your business logic.

Use APT_DUMP_SCORE and look at the score, I would wager that you are getting inserted extra tsort operators that are slowing down the job by doing extra sorts. Note that not only does your join data need to be sorted, but DataStage needs to know that it is sorted (through inserting a sort operator, ...

As Craig has already hinted, the problem might be in a nonbinary FTP or transfer from the host. Just create a UNIX file with an ASCII capital "O" (4F) and then push that through your CFF stage to see if you still have the problem.

Ray - yep, you are right. But at the moment I'm sitting in an office no more than 2 meters from Klaus

Can you run "orchadmin check" after executing the dsenv file?

Select the data in a job, sort the data in DataStage, use remove duplicates and the "deleted" entries from that stage to delete the records in the original table. Not fast, but it works.

While the DBA might be correct in stating that there are no errors in the database, he or she should be checking the locks, particularly deadlocks.

Declare the file as a long VarChar() or Char() string with no delimiters. Then, in a transform stage, use function such as DCOUNT() and FIELD() to parse the string into the 2 components you wish.

You could add a parameter to your sequence and use that value to conditionally skip parts of your sequence.

Even though the phrasing of the question sounds like an excercise question for an interview, I'll give it a go: 1. Partitioning. What method of partitioning you use makes no difference in the join as long as it guarantees that the join key is present in the same partition for all the input links. No...

The only thing I can think of is that the user's credentials aren't sufficient for write access to the project directory and/or the log files.

You need to find out which column is benig truncated and if it makes a difference. In a test copy, remove the columns one-by-one until you identify which one it is. It might be that, at 8.1, DataStage is more vocal about giving out warnings, meaning that you might have had the problem before, but ju...

Are you doing an explicit conversion from EBCDIC to ASCII in your CFF stage? Is that field declared as Char(1)?

Standard EBCDIC 4f is a pipe symbol, so that is good. But after copying it to UNIX it should still be 4F, so i am not sure what your value of "O" means - if the value isn't 4F then the error isn't inside DataStage.