DSXchange

How do you know from the log that they are performed simultaneously? The log's time granularity may be too coarse to separate operations that occur consecutively.

Craig has guessed what your data look like. You have to create the rules (in English, if you like) about what in the data defines the record type, then how to extract it if it's not in a field by itself - for example it might be the first character of each line. Then you can convert your specificati...

I don't believe what you are trying to do is legally possible.

The filter condition exactly reflects the mechanism used in the file to identify header, detail and trailer records. Ordinarily you would wish to separate these into separate outputs in your Transformer stage, therefore the "filter" conditions become the output link constraint expressions ...

The best way is to use Metadata Workbench. It has the ability automatically to recognise the situation you describe, and report on it.

Any 0 is FALSE, any non-zero value is TRUE. Try double-clicking on the default value cell to edit it. Even if it's not editable at design time, you can still provide a value at run time (though it may have to be TRUE, rather than 1).

It's not enough to add $APT_DUMP_SCORE to the job. You have to recompile the job, and you have to set the value of $APT_DUMP_SCORE to 1 in order to have the score logged.

The score is a log entry that starts something like "this step has n operators".

As I recall that was a bug that was remedied in the next version. Can't recall which version it was in, other than "yours".

Create a fork-join to identify the count from each key. Downstream of the Join, create a filter that passes only those key values for which the count is 1.

Suneel, you require a sorted list of employee names associated with each department number, as far as I can see. Is such the case?

Changing the maximum size of the caches will have no effect unless you are actually using the caches. There will only be a performance improvement if you are currently demanding more cache than the presently configured amount (in which case there will be warnings in job logs). Enabling row buffering...

There is definitely (it seems to me) a trend towards identifiers of the form oneTwoThree, in a number of languages including C, C++, Java and Python. Not so much in databases (yet?).

It makes (will make) no difference. The choice of supporting NLS at installation is what drives the internal storage of characters, not the value of the NLSMODE parameter in uvconfig. If you do change NLS mode a restart is required. However, it will make almost no difference to performance of server...

There's no real reason to change anything in uvconfig. It won't help. There are two reasons for slower performance, and you can't do much about either of them. You're now using NLS, which means you're potentially processing more than one byte per character. Internally, with NLS enabled, DataStage us...