DSXchange

Are you using WebSphere Transformation Extender or DataStage? This forum is for WebSphere Transformation Extender. But your language suggests that the question is about DataStage.

Once we know which product you're using it will be easier to provide a correct answer without having to guess.

Transformer stage with four outputs brought together in a downstream Funnel stage.

Probably search through an export file of the project for the parameter name.

Do you speak binary? Storage in Data Sets uses DataStage internal format where, among other things, all numeric data are stored in binary format. A Data Set is not intended to be a database (otherwise they would have called it that). A Data Set stores a set of data: a whole set of data.

...write into a .ds file. Please be aware that data are never written into the .ds file itself. This file is a descriptor that stores the locations of the segment files in which the data are actually stored. There is one segment file per resource disk directory per node, provided that there are suf...

Just a thought. How about a unique Sort on the first file then a Join with the second file? No need for global anything.

Neither the ODBC importer nor the Sequential File importer can read a file of this nature and turn it into a table definition. This will need to be a manual process (unless you create a job or routine to do it, to update the DS_METADATA table).

If the join keys are supported by indexes, then the equi-join in the database will certainly and substantially out-perform the join in DataStage. A further benefit is that DataStage will only need to process those rows that are the result of the join, rather than all rows from all tables.

When you exceed my post count I will be happy to consider your opinions about my professionalism.

You did not even acknowledge that I did provide an answer.

You can give a condition about whether or not to attempt the lookup, but you can not make the lookup itself conditional which is what your original post suggests. Perform the lookup with a Lookup stage unconditionally, and handle the condition elsewhere - maybe only load the records into the referen...

You don't need to do anything. They will be compared as strings, since at least one of the operands is a string. If you want to force a right-justified (numeric) comparison, use the Compare() function, whose third argument specifies the justification. In this case the space will be treated as zero.

What kind of UNIX? There are environment variables where you can tune the SPINSLEEP and SPINTRIES for mutex locks available for some UNIX platforms. But, as noted, ultimately the wait times being experienced, due to load, are longer than the smart semaphores (mutex locks) are tuned for.

Deleting the ROOT record - even if you had the correct SQL syntax - is not going to achieve anything useful. What exactly do you want to accomplish?

Why not re-import the job from one of your recent backup exports?

Why don't you have support?

No. The Join stage has only equi-joins on the identified join key columns.

1) Yes, possibly easiest is via inspection of either an export file or the records for that job in the DS_JOBOBJECTS table.

2) You are correct. You may wish to submit an enhancement request around this one.