DSXchange

That line number is pretty close to 65536; I wonder if there is a correlation. could you post the .dsx text lines 63945 through 63960?

Regu, the file system isn't ruled out completely, I would test the hashed file write on both a ufs and vxfs partition to make sure. One glaring difference is that sometimes on certain file systems UNIX sequential files are sparse, i.e. if you write to a new file to position 1,000,000 it will not imm...

DSguru - I grew up on the all caps in UniVerse as well and can't get used to inverting the case. So instead of changing the case I've become very adept at the double-copy-and-paste or "repasting"; I paste it into the command line to get mixed up casing, then copy and past that line again to the comm...

Try "lsfs" on your system to see what file types you have.
Enter "$DSHOME/bin/smat -t"; the configuration options that have been changed from default are marked with "*"; are they the same on both system (actually, a simple diff on the $DSHOME/uvconfig files will work just as well, if not better).

I see - I saw that this was posted in the Server forum and that changes things. Put your reject link to a transform stage, then onto to whatever file output stage (or a PEEK stage) you want. In the Transform output details tell the job to abort after 1 rows down that link.

You have a reject link somewhere in your job as you specified in your original post. From which stage is this link coming from? Also, look at "Linking" in the DataStage Designer Guide starting at page 4-14.

My first thought would be to look at the file system on which the hashed file is performing slowly; is it the same basic type as on the other machine and is it busy from another process? The other The configuration parameters for hashed files ni DataStage pertain mainly to factors involving concurre...

If you have no transform stage and don't want to put one in, then you should use the reject link as your abort trigger as mentioned twice above.

Saur_classic - The job should run the same way with the same input data each time. If you are 100% certain that the source file is the same and the Teradata table has the same state then you are right in looking for the problem in DataStage. Have you tried a 1-node configuration or sequential execut...

I'm not on a system where I have DS installed, but I seem to recall that DSStopJob() function can only be used from the controlling job. If you need to abort a job from the job itself you need to call DSLogFatal() . Better is to set the number of links output down a link to 0 so that the job aborts ...

I'll assume that the sql works from the command line. You need to specify a lookup stage and use sparse lookups; I'm not at work so can't give you the exact syntax but you need to specify a dummy input key column and use that in the SQL (so that DataStage actually performs the query for each row).

saur_classic wrote:...Does this mean that metadata is changing for records between 148 to 200 ?...

Probably. If you change your job to run on 1 node or in sequential mode, and output to a peek stage instead of to Teradata you should find the row that is causing your problems.

ArndW wrote:...Using a reference lookup to a unique Oracle sequence is another option, but it will severely impact performance...

Havoc - this is a solution

saur_classic, although you stated that "the Metadata for both files is the same", the error message from DataStage is

...column descriptor count does not match field count...

So there is a difference between the format of the two files.

Convert the dates to internal format and take the difference,