DSXchange

OK, it works fine in 7.5.2 without RCP. So is it version 8 or is it RCP? Can you run a test (maybe a separate job) that does not use RCP? If that works, then RCP is the culprit: if it fails the same way it's a "feature" they seem to have introduced in the new version.

These days the 32-bit drivers tend to be in a directory called lib32 while the 64-bit drivers tend to be in the lib directory. Make sure that lib32 occurs before lib in your shared library search list, at least for DataStage processes.

Define "performance" in an ETL context.

Not failing would be a good start point.

Store the one-liner as a Transform rather than as a Routine.

Pivot stage.

You may need to parse the comma-delimited string into separate columns upstream of the Pivot stage, but once that's done you'll have a working solution.

Then I suggest you look for files wherever they are documented by the developers as having been written.

The reason for having a separate uvodbc.config file in each project is, as the documentation states, to give you the flexibility to access some, but not all, DSNs configured for DataStage from that project.

Get yourself a premium membership and read the remainder of my earlier post. Premium membership is less than 30c (Rs12) per day. Among other benefits it allows you to read posts by the five premium posters in their entirety. All revenue from premium membership is devoted to defraying the hosting and...

As stated, there is no way to set a row limit for a parallel job (unless it is compiled in trace mode, which carries its own penalties and is only intended for diagnostic purposes) without designing one in. For example you could compare the row number in a Transformer stage with a job parameter's va...

Not sure of the cause. Obviously having zero rows of source data is the culprit - and a good workaround would be to check for this situation before starting the job - but why this happens is not clear. A DataStage job can manage a "zero rows" scenario in most cases, why not this one?

It's a non-trivial process. The way that you set up the project (via copy commands) is so totally wrong. You may indeed be better off to delete the project directory then to clean up the system tables. The basics of cleaning up after deleting a project are described in this paper but there is likely...

You are thinking like a server job developer.

For parallel jobs there is no way to set a row limit with the job compiled normally. If you compile the job in trace mode, only then can you set a row limit. And it's a row limit per node.

It's the underlying command used by the Data Set Management utility. It is documented in the Orchestrate Administration manual.

Try VarChar(4000).

Arnd is apparently thinking of the parallel Merge stage which works differently. The server Merge stage directly reads two sequential files and effects a join between them. As you say, it has no View Data capability. But that should not prevent you from using some other utility, external to DataStag...