DSXchange

I believe a patch will be tested before releasing by IBM. Ask them whether any other client have been provided the same patch and whether they encountered any error like yours. If you can provide more information on the errors you receive (after installing the patch) others can see whether the same ...

I assume the user is mapped to dsadm.

What if you place a big file (say 1 or 2Gb for now) in the Oracle server and attempt to ftp it across to DataStage server (and viceversa)?

How long does that take ?

Or if you design a job with "select dummy from dual", how long does that take to start?

Are you saying that 'select * from table' takes 25 minutes to start !!??

Can you connect via Director and Admin ?

To do you, we need information about your query and any issues with the query - such as doing a full table scan due to missing indexes etc.

Can you provide a glimpse of your query so others can see what is happening ?

In that case, try to optimize your SQL in Oracle itself. Alternatively you can break into datastage references and joins - if it simplifies and improves

What if you make it Varchar(60) or something similar ?

This is a very open ended question. Similar issues are discussed several times before. What is your requirement? There are many variables such as number of tables sourced from, transformation logic, space available, volume of data, machine capacity etc etc etc etc So better do on a case-by-case basis.

Personally I think the source is not the bottleneck. It must be the sort and agg in DS. As you said you are not doing anything in tx, you may be better-off doing the whole in Oracle SQL itself. Something like Insert into...... as Select ...... Group By ...... This way you avoid the transfer over net...

What if you set a constraint in the transformer as @FALSE ?

Also is both client and server of DataStage running on same PC ?

Add an external source stage with 'env' as its source program.

As long as you do not change the PROCESS_NUMBER column in the table it is max() from, the value will remain same. In other words, commit the max(PROCESS_NUMBER) + 1 back in the table after successful completion of current run. If it is from the same target table where you are loading the rows, then ...

You can fetch the OS process number of the process leader.

Best way is to hold and external control table and populate it with job run information.

Have you provided any default connection details in the stage ?