DSXchange

These files are created afresh when the new project is added.

You could, of course, copy them from the Template project afterwards.

But there's nothing in the product itself to do this.

Have you enabled row buffering, so that the Transformer stages are now executing in separate processes?

Variables declared to be in COMMON memory are limited to a single process.

This might be causing the effect that you're describing.

When the query type is "generated SQL", the "other clauses" field is enabled in a DRS stage that is feeding a stream input, but disabled in a DRS stage that is feeding a reference input. This is correct behaviour. The assumption is that, in a reference lookup, you're retrieving one row, so that GROU...

You can always run another output from the Transformer stage containing just the value in question, run that through an Aggregator stage with its aggregate rule set to "Last", and from there to wherever.

There's no limit based on number of rows. However, the default hashed file has an upper limit of 2GB; you need to prevent it from hitting that barrier or it will become corrupted. Monitor the size and, if it exceeds, say, 1.5GB, take action to convert its internal pointers from 32-bit to 64-bit poin...

On a single CPU machine DCWRITEDAEMON should not be set too low (say not below 10). This is the multiple of 10 milliseconds that the daemon pauses between writes. On a multiple CPU machine lower values are OK. High values, like the 20000 suggested by sanjay, mean that it can take up to 200 seconds (...

If you want to be able to see F1 by default, you need another entry in the file dictionary for SDKSequences.
This means that F1 will be displayed when is executed.

VOC is the DataStage vocabulary table (which is a hashed file). Because there is no definition for a column called F1 in the file dictionary of SDKSequences, a neat trick whereby a query against one hashed file can use the file dictionary of another hashed file (via the USING phrase) is employed in ...

Do you have some proof for this claim, Mandy? Even if you are on an operating system that only supports 2GB files, a fileset can contain many physical files, so there should not be any limit to the size of a fileset. Chapter 6 of the Parallel Job Developer's Guide provides all the extra information ...

The expression "can of worms" comes to mind. A "dictionary item" is hashed file terminology for "column definition"; these are actually optional for hashed files, as navigation of "real" data is positional rather than by name. For virtual columns, such as those postulated, a column definition can be...

The link row counts are directly accessible using DSGetLinkInfo() function.

analyze.file can also be executed from the operating system shell (and therefore use a pathname); the executable is in the DataStage Engine's bin directory.

ACCOUNT.FILE.STATS does require VOC pointers; search for SETFILE.

Records within hashed files (either type) are stored in "groups" (pages), the size of which is determined when the hashed file is created. With static hashed files (and for the MINIMUM.MODULUS setting for dynamic hashed files) you need to ensure that you have enough groups to store all the records. ...

No, there's no nexus between database partitioning and data partitioning within DataStage. You will probably find performance optimal if the number of nodes is a whole divisor of 360.

CoSort plug-in is not part of DataStage; it's a third-party product (that is, more budget). You can find out more and request an evaluation copy from Tools4DataStage . It's particularly valuable for large sorts. I'm just back from a project with an Indian telco; imagine the sheer volume of CDRs they...