DSXchange

Any time you see that it's bad code in the client software. It's a Windows error indicating that the programmer has used a short cut, naming the property/method without its object, and it's backfired because there's a path through the code in which the object is not set. For example the following wo...

The blocking fields require an exact match - the probabilities are ignored for these. The probabilities only come into effect to ascertain whether there's enough aggregate match weight in the remaining columns to determine a match. So it appears that you are on the right track.

Not really, if the sources are flat files. Adding more memory might help, if system monitoring shows heavy paging/swapping activity. QualityStage itself has no controls that you can tweak. A final thought; are you processing any unnecessary data? If so, remove this early in the processing stream.

Can't help you - I disabled this due to being overwhelmed by it.

Which probability are you specifying, and where? The match weights are based upon two probabilities; you can read about the mechanisms in the user manual.

Step 1 is to define what you mean by performance.

Step 2 depends on where you are getting your data from. For example, doing a GeoMatch where one of the sources is a database table you can create extra columns for the standardized forms in that table, and index them.

View Data is documented as not working for File Pattern.

The metadata importer has some problems. Try importing it as an Orchestrate schema definition - use the third option (from database table using orchdbutil).

You'd better show us HOW you are "checking for denominator", since DataStage is still claiming an attempt to divide by zero.

Your basic premise, that the job log is a text file, is incorrect. It is a database table within the DataStage Repository. The dsjob command executes an appropriate query to retrieve the information, then reformats it. If you want that information into a text file, redirect stdout of your dsjob comm...

If you specify N readers per node, then each process will read 1/Nth of the rows from the file. A sequential file is, by default, read only on one node (that is, the stage executes in sequential mode) and the data are partitioned subsequently. If you have multiple File properties, or you are reading...

DeepakCorning wrote:Ray ,

Nope the constraint would not work as there can be multiple row returns as the Field3 is a important decider to select the correct one.

Not a problem - elect to use multi-row returns (that will mean using a UV stage or an ODBC stage).

The point is, Mod is a function, not an operator, in DataStage BASIC.

The same is true of Not.

NVLLVS ANXIETAS

If you have multiple CPUs (or even sufficient spare CPU capacity) you can create multiple instances each of which processes a subset of the rows - partition parallelism, in short.

MVS - mine's very slow.