DSXchange

What output are you getting in PX and have you tried it with a 1-node configuration file?

Your example has 4 columns in both rows.

You've run out of temporary disk space. You can either increase the available disk space pointed to by your APT_CONFIG file or reduce your disk requirements - perhaps you could pre-sort your data by doing an "order by" in your selection.

It is not quite clear what you are having problems with. Surrogate key generation is unique across all nodes and ordered within each node. If you have multiple nodes and write to a sequential target your ordering will not sequential. Either run on 1 node or put a sort on the surrogate key into your ...

Define "recordid" in your context and you will get a better answer.

Which stage is output? With a lookup stage, you would need one source stage, one reference stage and an output stage - that makes at least 4 stages for the job - or is it a sequential stage in addition to your CFF stage? No matter, still do the same, replace candidates with peek or dummy copy stages...

What stages do you have in your job? Make a copy of the job and replace output stages (one by one) with PEEK stages to see if the error goes away. Try running with just one node in your configuration file and disable operator combination.

Stages such as the aggregator will store the minimum amount of data necessary. If the input stream is sorted by Columns A and B, then an aggregate function on Column B would only need to store/process data for one value of Column B, once that changes it knows that no further identical values of Colu...

Without looking further into the issue, I do know that the High-Value of a PIC X and PIC S9 COMP-3 are different values so that if the are in the same location, as specified with the REDEFINES, you can only use one or the other. It would seem that MAX-FV was set with high value, making the value of ...

Don't use a routine to do this in PX. Either the surrogate key generator or you can also use functionality for surrogate keys built into the transform stage.

Unfortunately that will not work. Since hashed files physically only have one non-duplicate key, your multiple keys actually get concatenated together with a separator (@TM) by DataStage to form that single key. Therefore you cannot just use to a subset of the key for a lookup. While it is possible ...

Please post the complete error message. Also, try doing a reset of your job and posting the "from previous run" titled log entry, if present.

No, not quite. The partitioning algorithm is not a factor, just that all the records that you wish to join need to be in the same partition on all links - effectively meaning you should use the same partitioning algorithm for all partitions. The topic of using explicit or implicit sorts has been dis...

DataStage will detect that difference and resort implicitly (turn on APT_DUMP_SCORE to check). If you disable this functionality, i.e. through APT_DISABLE_SORT_INSERTION and sort your two links differently as you posted, the job will abort.

There is a whole PDF documenting the differences and link caching functionality, but in most cases it is not necessary to turn on this functionality. Just load your hashed lookup file to memory (just those columns you intend on using) and DataStage will, in almost all cases, do a quick and good job ...