DSXchange

Why not? DSGetJobInfo() does.

You do need to re-compile the job sequence after changing any of the compilation options, like "automatically handle activities that fail".

There should be an optional property Sessions per Player in the DB Options folder.

dsdoubt wrote:Any inputs GentleMen?

Be patient, particularly on weekends. Remember that the rest of the world begins their weekend before those in the Americas do.

If it's any consolation, they begin their work week earlier too.

Is the job successfully compiled?

So what's the problem? All the rows were exported successfully.

The "will partition despite..." and "cannot preserve..." messages have been discussed at length on the forum, a simple search will find them.

It's not a bug. It is an alert message. You can demote it to informational if you wish. Entire partitioning is implemented through shared memory on SMP systems: if you choose some other partitioning method DataStage alerts you to the fact that it will not be using shared memory. It does not need to,...

Welcome aboard.

Stopping a job like that is a Bad Practice and should be discouraged from the outset.

These functions do not ship with the product.

Yes, but only if your default or specific date format string is "%yyyy%mm%dd".

This is not a function that ships with the product.

To put it another way, only numeric values can be summed, averaged or have any other numeric function applied.

You need to increase either the number of nodes in your configuration file or the number of sessions per player in your Teradata Enterprise stage.

You already have it:
Trace=Yes
TraceFile=/tmp/trace_psqlodbc.log

But, if the driver can not be loaded, it won't be up to the point where it can trace what the driver is doing.

The UniData server does not have to be on the same machine as the DataStage server. An entry in the uvodbc.config file tells DataStage where the UniData instance is.