DSXchange

Sumit,

it would be very helpful if you could tell us the error instead of letting us guess with

...I am getting error when...

I was fighting with that same issue yesterday when I saw this post. As Ray stated, the unbalanced quotes need to be fixed at the source and trying to do so in the read pahse is too late. You need to make sure that the file is written using quotes in the creations stage, that way any internal quotes ...

I don't see any error message - what do you get when you hit the "more" button on the compilation?

This is not the original question, but to answer it: setting parameters should be done in the sequence that calls the job, as you've already correctly surmised. It used to be possible to change a job's parameter values in the job control, but this functionality was removed and the code you are using...

Putting an IPC stage or several of them will only help if a DataStage job is CPU bound on the DataStage server, in this case the bottleneck will not be CPU but database I/O so an IPC stage won't make any difference to throughput.

I thought the merge stage didn't take any input links, just the file names defined therein You should get a warning message if you read those files through a sequential file stage with the "contains termintors" attribute set to "no" with unbalanced quotes so you could check that. Also, try defining ...

devnull - what we are saying is that the undocumented stuff will cease to function. Any documented features such as before-subroutines will continue to work.

The error message comes from ORACLE, so the DBA should re-check. Note that it is not the tablespace but the UNDO logs that are full.

Kris,

the message says it all - the data for that row can't be parsed because the quote character is not balanced. Check your defined quote character in the merge stage and check your file's contents.

You cannot, this is a command that needs to be executed in TCL or from the ADMINistrator command.

I think I did jump the gun there, just associated RTI with being able to transfer data with http. I still can see an http session doing a bulk data move in an automated fashion, even ignoring the secure part.

There is a very powerful command in UNIX called find. Try attaching to your root directory and executing find . -name orchora* -print and it will probably show you 3 files and the path that you are looking for.

When this job is archiving data to a subdirectory, another sequence also tries to archive its data to the same directory and as it not able to access the path, the second job is failingand getting aborted. This is not a DataStage limitation, it is an OS file system limitation and there is no workar...

there is no backup and no restore mechanism for DataStage log files.

How about a simple job to read one record from a table (you could do something like a select from dual in Oracle) and writing that to /dev/null. If the job fails then you don't have a database connection.