DSXchange

The flavour/version of Linux is also important as different flavours/version of linux use different compiler versions and DataStage Enterprise only supports certain compiler versions.

The parameter for invocation is "DSInvocationId" (case sensitive)
So the invocation ID of the sequence can be passed to jobs controlled by the sequence by passing the runtime value of DSInvocationId.

Are many developers using the compiler? with some setups, you have to obtain a licence before the compile can start. You may have only a few licences and lots of developers. Or the compiler might be 'hanging-on' to the licences for a while before releasing them back into the pool?

The Basic transformer uses the Basic engine. So there will be a performance hit while you pass your data between the Basic Engine and the Parallel Engine.

You specify the location of the external libraries in the PX routine.

You may also need to check permissions, the DB2 users may need access to the resource disk as well as the user running the DataStage job.

You need to find the Hex or Oct code in the UTF8 file for the junk character. You can then prove if it is an ASCII character or not.

To fix the PWD error, you should start the DataStage Engine under a sh shell rather than a ksh shell.

You can't reference a Job parameter in a buildOp, but I think you can pass the Value of a job parameter into the BuildOp as one of the arguments.

Check out the \Samples\TrxExternalFunctions folder in your client install media.

also "working with parallel routines" in the managers guide ...

Are you trying to use the special environment variable $ENV ?

Doesn't an apt change require a server bounce? Nope. If you make changes with the Admin client Environemt / Job design (job environment parameters) then the values are taken at run time. Only if you place variables in the dsenv file do you require a DataStage server bounce. Anyway after thinking ab...

I guess that as the DB2 stage is running in parallel and so the close command is being run 'once for each node' and thus causing the deadlock. If so you'll have to force the job to use only one node.

Try running the job with only one node in the DataStage/Configuration/<FileName>.apt ?

If you job design uses a buildop then you must generate it, which will create files in the buildop directory.

How are you sure you are deadlocking yourself?
Are you using user defined SQL?

My understanding ... You have to definie the Key when you create the Lookup FileSet. This schema info is stored within the FileSet and thus can not be changed without re-creating the FileSet. When the job runs (maybe for compile too?) the Key (schema info) is read from the Lookup FileSet rather than...