DSXchange

The first thing you need to do is to be sure you've named the correct culprit. Create a job that consists only of a Sequential File stage and a Copy stage, and measure your read speed with that. You could experiment with multiple readers per node in this job too. I strongly suspect that the problem ...

Welcome aboard.

Review the addCustomMaps.sh shell script and note how makeconv is invoked. For example, its parent directory may need to be added to your command search list (PATH environment variable).

... and on the database side of the job?!!

There are no statements in a Nested Condition activity. All you need are the (Boolean) logical expressions. Use the expression editor to build your expressions, so that you get the syntax of the parameter reference correct. All you need in the expression is

Assuming a default installation: /opt/IBM/InformationServer/logs

I can not guarantee that whoever installed at your site used the default location.

All DataStage processes are background processes, so the question of response time is moot. Memory demanded is largely a function of design. Using less memory can in some cases cause slower execution time, rather than faster. Doing things on disk is substantially slower than doing the same things in...

1. Design time information is local, other information both.

2. No, local table definitions in DataStage are purely local. You have to use the Shared Table Creation Wizard to convert to shared.

There is one database for all. Look in the Information Server install log. That will report which database was used. Install logs are usually to be found in the logs sub-directory within the InformationServer directory.

No.

But you can buy time through Amazon on a "DataStage in the cloud".

Search DSXchange for details.

Then take the IBM classes, or attend Information on Demand conference. Both of these will provide topology diagrams.

I'm pretty sure they DO occur in the Installation Planning Guide also but am not in a position to check.

I believe I answered that already.

But please advise what you mean by "performance" in an ETL context.

Only if rows/transaction (transaction size) is set to 100.

If rows/transacton is set to 1, COMMIT is sent for every row. If rows/transaction is set to 0, COMMIT is only sent after all rows have been processed.

There exists a stage for connection to UniVerse databases. There is no connection between DataStage and UniVerse other than the historical one, that DataStage originally used UniVerse as its repository and engine. While the local repository database and server engine still look and behave quite simi...

Look at what's under the red mark. Open book is shared, blue-and-yellow grid is local.

DataStage does not support CLOB. Perhaps the "working" environment is effecting a CAST to Long VarChar?