DSXchange

Putting in those parameters shouldn't affect the startup process. Does the job fail again if you remove the two parameters?

The first question is whether your license.xml includes PX or just server jobs. From the UNIX command line in your $DSHOME directory execute "bin/dslictool" to see what licenses are actually installed.

DataStage PX often uses the VarChar length definition as if it were fixed length and thus uses more storage on sparsely filled strings than if the Varchar fields were non-terminated. You can test this by writing a dummy job with a Row Generator stage creating one column of VarChar(1024) and filling ...

What I am saying is that I don't think that there is an ENV setting to change this behaviour.

Nulls don't get written to or read from sequential files, so one needs to put in null handling or default. But "BESTAND" (this is probably a SAP system since the variable name is German) is most likely numeric so your default would need to be a numeric value, not a space.

I don't know about the first, but for the second problem go to the stage before the lookup and then specify "clear" for partitioning the output.

This would be a standard windows uninstall, so perhaps this link might help you further:

http://www.tech-recipes.com/rx/2947/win ... mand_line/

I took a quick look and didn't find any APT_ variables, but that doesn't mean that there isn't one. But your problem does illustrate that use implicit type conversions can be problematic. In this case I would declare the variable as numeric and then perform an explicit DataStage number-to-string con...

Are you using "Affis" in a stage variable? Turn off operator combination (set $APT_DISABLE_COMBINATION to "true" for the run) and ensure that the error is being generated in your transform stage.

The simplest solution would be to create another table based on Table 2 that contains just the group and the top-level parent (perhaps in another job) and use just a single lookup without iterations.

Job Sequences can call up external programs when a job fails. Thus, any method that can be called from the command line can be used to inform of job failure.

You have posted in Server but marked the job as Parallel. How this question is approached is very dependent upon which type of job you have. Server jobs can use the concept of multivalued fields which are perfect for this type of problem, but Parallel jobs would need to handle it differently. Also, ...

'12', per your logic.

The stage vars should be [1,8] and [10,8] respectively, I miscalculated.

You cannot. Without external calls or without writing your own c++ buildop you don't have access to this data from within a PX job.