DSXchange

Oh yeah. I don't know if this holds for other databases, but for DB2 if the input and lookup tables are in the same database, it's most efficient to do a join in the DB2 read (in this case an outer join), since DB2 does a better job optimizing retrieval of data from its database than DataStage does...

Chulett,
I ran a test job without the commas and it worked fine.

You can use the Convert function in a Transformer stage. Syntax: convert('From List','To List','Expression') In From List, you can specify the list of special characters that needs to be replaced In To List, you can specify the list of new characters that will replace the special chars. In your case...

Tiozzo,
I agree with DSGuru. In our project, we too are having the authentication details in a separate file and pass it as job parameters during runtime.

As Raja said, the Join stage is better than Lookup stage when volumes are high. You can still lookup on multiple tables by using a DB join in the database stage.

Are you only migrating data from source to target i.e. without any lookups or joins with other tables or transformers? or any other stages?

We too faced a similar issue. We were creating temporary datasets in our jobs which were not deleted and started eating up the space. You can have a UNIX script to delete such temp files or datasets and put it as the last stage in your sequencer in an Execute command stage. This way you can ensure t...

You can check if the data to be loaded is sorted on the index keys of the table.

Can you give the full path of the Etlstats folder?

You can use a SORT stage before the AGGR stage to sort the data and the partitioning must be on the same fields as the grouping keys in the AGGR stage.

You could run through the following checks, 1 - Is your target database partitioned? If not, DB2EE stage may not work correctly as it will not be able to load data parallely. You should be using a DB2 API stage 2 - If your target database is partitioned, check if the partitioning type in DB2EE stage...

I'm sorry. Since we had encountered this issue several months back, I couldnt recollect it correctly earlier. The time-out value was actually set in DS Administrator. The "inactivity timeout" value was initially set low which caused the UNIX process to abort. However the DataStage job was ...

This looks like a UNIX process time-out error. We used to get a similar error when the DataStage job continues running more than the time-out limit set in UNIX.

You can check the partitioning type specified on the link.