DSXchange

Sort your input file on the key in DataStage, then use 2 transform stages and stage variables to detect duplicates and split the 2 streams. Sort 1 sort by ascending Key Transform 1 Stage Variables svDuplicate : IF In.Key=svLastKey THEN svDuplicate+1 ELSE 0 svLastKey : In.Key Add column DuplicateNumb...

Does your config file reference multiple nodes?

Just as a test, login to a UNIX shell as dsadm, and try "touch /tmp/testfile.txt" - does that work? Also, if there are any files in the /tmp directory starting with APT... who are their owners?

Server sort stage, right? and are you 100% certain that you aren't running out of disk space (assume your whole file lands in that directory temporarily)

Why not do your truncate as part of the before-sql?

The Load method is executed outside of DataStage and that is why the single rejected rows and messages aren't visible the way they are with 'upsert'. I think that the error log files should be visible after the job run is finished and has errors, and that file can be read and interpreted.

Rohith,

please use the Search functionality before posting questions; in this case there are 21 thread matching the search terms "command line compile", and this one is just an example of one of them that answers your questions.

Typically neverending jobs are causing by blocks or locks on the database side. Try your job writing to a peek stage instead of to Oracle. Does it hang?

Now that you've fixed the path issue, you have hit the next common error, discussed many times here. You need to source the "dsenv" file in the $DSHOME directory, this script sets up the environment and maps the directories. From UNIX the usual command is ". ./dsenv" when attache...

And I'll chip in one word as well - "Use"

Now push them all onto a stack and then read :D

In this case I think it is the multiple columns used for the key that is causing the issue, particularly if the file creation metadata and query metadata are not the same. But generally it is as Craig has stated, that unseen spaces cause fields that look the same to not match.

Your first step is going to have to be to make an upgrade plan and decide what level of testing you will need to do in order to satisfy the customer quality requirements. I would also tend to the recommendation of getting or hiring someone with experience to do this, but with a lot of effort you can...

I still cannot understand the exact problem.

Can you change your job to write to a sequential file or PEEK stage, does that work correctly? If yes, then the cause is most likely in the Oracle portion. Do you have specific SQL in Oracle?

You've posted a SQL query, but haven't actually specified if this is the source or target. What is your source data and what is your intended target and what form do both take?

What do you mean that you cannot find the log? What is meant here is the output from the job and is visible in the Director for that job.