DSXchange

Inspect the generated OSH and/or the score to see where this item has been created in the job design.

Please search the forum for this error message.

It has nothing at all to do with transactional volume. The fork() function is involved in getting processes started.

Not without knoing the exact original error messages and which files you copied, and with what commands.

You create the routine outside of DataStage. You compile and link it outside of DataStage. Then, within DataStage, you create a "new parallel routine", which is actually an entry in the Repository that tells DataStage where to find your routine and with what arguments it needs to be called. Your alt...

Note that there is no date zero.

You should also have found the Matches operator in your trawl through on-line help. would do it, as would

Instead of Xfm -> UV -> HF it suffices to use Xfm -> UV.
In this case the CREATE TABLE statement is likely to persevere.
If it does not, involve your support provider.
What exact release of DataStage is this?

Have you tried setting DSHOME environment variable?

Have you tried setting DSHOME environment variable?

Describe your job fully and accurately. If you must, post the generated OSH. Ideally, post the score.

Push back (intelligently and constructive) against illogical client requirements.

Then search for vertical pivot, for this is actually what you are trying to achieve. There is no single "out of the box" technique for vertical pivot, but there are at least three ways to do it in server jobs.

Yes.

In a Transformer stage. This will mean that no rows will be sent to the table you've dropped.

Note that Craig's original answer specifies a server job.

You can use a parallel job, but would need one ODBC Enterprise stage per table.

First, define "performance" in an ETL context.

This may help you to get a better handle on what is meant by "optimal" in this context.

Note particularly that rows/second is an almost entirely meaningless metric, as I have posted on a number of occasions.