DSXchange

I believe a more generic solution is needed, Gokul. For example

AA 1
BB 1
CC 1
AA 2
BB 2
CC 2

should yield

AA BB CC 1
AA BB CC 2

Your approach does not handle this; it can only ever generate one output row.

That question is best answered, at least initially, by you reading the Parallel Job Developer's Guide (parjdev.pdf), especially the sections on Custom stages.

Welcome aboard! :D

Of course you can set this property. But consider carefully what the implications are. If you used DISTINCT in your extraction query and you are getting warnings about duplicate values, doesn't that ring any alarm bells at all?

What you are asking for is a vertical pivot. The Pivot stage performs horizontal pivot (one line to many), but definitely does not perform vertical pivots. Several techniques are available, depending on exact circumstances. For example is there a small, finite number of columns to be generated in ea...

1. Your system is overloaded. You are asking it to do too much. Also, you're probably reacting to single snapshot - every process takes it in turn to sleep awaiting its turn on the CPU, if it's not waiting for something else such as disk I/O requests. In fact, there can be no more than N processes a...

Use a Switch stage.

Nothing, except maybe an abort.

Operating system rules prohibit more than one writer to a sequential file.

Why can't you just get the max of the string[10] field? You can do it in SQL, so you should be able to do it in an Aggregator stage. Dates in ISO 8601 format - which this is - sort properly, at least in the year range 1AD through 9999AD.

The clients do not run on UNIX. You have specified that you have a UNIX-based server. There is no way the same machine can run both UNIX and Windows at the same time. That is why you need different machines. The only exception is if you are running DataStage on Windows (which you specified you are n...

The metadata must be the same (including the additional column) on both the input to and the output from the Sequential File stage. Your SQL must deliver exactly the same number of columns as are specified on the output link from the ODBC stage. There's some good material in on-line help; next time ...

Depending on which variant of UNIX you are using, you will need to change some kernel parameters. This is documented for your particular platform in the installation guide and in the readme file that ships with the software.

Different.

You specified UNIX. The clients only run on Windows.

Please clarify your concept of "constraints".

"/n" would never work, you need "\n".

If that's no good, you can try @FM or @VM system variables, or explicitly incorporate Char(10).

Maybe there are enough rows in production to exceed the hashed file cache size limit (default 128MB) but not in development or test environments?

Try increasing the read and write cache sizes in production, using Administrator client, Tunables tab.

Please start a new thread. There is an answer - we can post it on the new thread. Specify exactly what your client wants - if you don't know, force your client to clarify.