DSXchange

Ok, I missed that. I thought the OP had used both in the SELECT statement and that the values (and syntax) didn't match.

My firs thought is that the embedded single quotes in the parameter are not making it to the query correctly. Can you see the parameter value, with single quotes, in the Job Log?

Odd, I found this thread.

As with all errors that are from the combined operator controller, turn off operator combination first to localize the stage causing the error.

What value are you passing for the parameter or typing in during your SELECT and did you intentionally not put hash marks around the parameter in your SELECT statement?

Never use "kill -9", it will ensure that the process is gone in the OS but it will remain in DataStage and potentially block processing because it holds locks and resources. From UNIX, in the same $DSHOME directory as before, do a 1. "bin/dssh" 2. "LIST.READU EVERY" 3. "QUIT" does the PID show up?

Round robin "cheats", since it guarantees that all partitions have data (assuming you have records => number of partitions); but it doesn't solve the cause of the problem. I think that it would be a good idea to involve your support provider at this point in time, since you have a reproduceable simp...

This problem is familiar and I know it has been discussed in DSXChange before; but I haven't had any success finding threads using the facility. At least the solution was easy (once you knew the correct key sequence to enter).

Due to historical reasons, DS sometimes cuts off PID numbers (back in the old PRIMOS days they didn't envision 6-digit pids). If you do a are any processes shown?

Normally you drop the Oracle stage on the canvas, fill in the column metadata and connection values and you are done. What have you done so far, and what is the problem?

ArndW wrote:reset the job and look into the log entry "from previous run" to see if additional information is available.

Did you append the 1st record to the end, or replace the last record? Also, is the error still in the n-1 position?

There is not a builtin method that will do this for you automatically, as string truncation and data conversion is automatic. You will need to put checks into your job to ensure that the data is correct..

Tell us about your use of the EMPID stage.

reset the job and look into the log entry "from previous run" to see if additional information is available. Also, try adding one more record to the file (copy the first record to the end) and see if the error is now n-2, which would mean the actual data record is bad, or still n-1.

If you can't avoid updates, try using partitioned tables or parallel processing to the database. Change the upsert in DataStage to ensure that you always try the update first, then the insert. Talk to your DBA about what options are available in the database to tune the job.

We see this error when someone has decided that the "XMETA" instance isn't being used by anyone and brings it down. In this case the new IP server might not "see" or be able to connect to the XMETA repository. As raycheung mentioned, the java log file, while extremely verbose, should contain more in...