DSXchange

Process metadata for the perfomance analysis tool are collected into XML files (in the XMLFiles directory). This might have something to do with the error that you are seeing. But I really believe that its more likely to be an issue with the Job Monitor.

The only possible solution is to prevent the deadlock from occurring. First, I guess, you need to use something like Teradata's PMON to determine where the deadlock is, then identify the cause, then (if it's in your DataStage jobs) eliminate the cause.

Sequential File stage is a passive stage, and does not do any work (apart from formatting columns) on the data. Transformer stage is an active stage and is where the work (for example adding the call ID) must be done.

My bad. dscc is the client-side command line compiler.

You might investigate field #31 in the JOB record in the RT_CONFIGnnn table for the job.

kvshrao wrote:Go to Advanced Find and check the last modified timestamp

Last modified is NOT the same as compiled timestamp. I might work on a complex job for a number of days before my first attempt at compiling. Every time I save (which is frequent) the last modified timestamp is updated.

You could do a Right("0000":<field>,4) or maybe even a PadString("",0,4-length) : <field>? According to the help files, padstring does append Instead of hardcoding the 0 use Str function to generate the zeros equal to the length of field. right(Str('0',4):<field>,4) All function...

Sampling is at 10 second intervals, unless you've changed this via Options. This is pretty coarse sampling, particularly for small volumes. Further, rows/sec can include wait time for the generating (extraction) query to start delivering rows, which can be substantial (for example if the query inclu...

tcurcio@us.ibm.com wrote:So, it cannot be April 2015 since that would mean less that 12 months.

Thanks, Tony.

That was my guess 14 months before April 2015.

You can not supply an IN list via an element of the ORCHESTRATE collection.

I would create jobs to use each, and process a statistically significant number (millions) of rows through each, controlling for things like caching. Use the player timings and other environment variables, and/or DataStage performance analyzer, and/or Operations Console to perform the measurement.

It's a good approach provided that the engine has sufficient capacity to run that many invocations simultaneously.

Pretty sure there's not. Nor does the Surrogate Key Generator stage give you the possibility of using a job parameter - the only choices are "system picked" and "user picked".

Enhancement request, perhaps?

I make a lot of use of this functionality loading to Teradata (replace the work table then populate it using FastLoad). It does not fail when the table does not exist. Must be a database-specific thing. Check also any "fail on error" properties that might exist in the Connector stage.

Actually, in this specific case, there is probably an implicit conversion performed from decimal to string, since the Field() function requires a string data type as its first argument.

I prefer not to rely upon implicit conversions in parallel jobs.