DSXchange

Is there an entry for <pit_mms> in the uvodbc.config file in your project directory?

Then option 3 is not for you. Try option 2.

Seems to me that a table with no unique columns is a strange choice for a lookup table.

The value 0, of course, means that all rows are part of a single transaction. You need to ensure that your Oracle rollback segment is large enough to accommodate this.

Iconv() is an exceptionally clever function. For dates all it needs is the day month year ordering (and not even that if the date is ordered correctly for your locale).

Therefore an elegant solution is

Not enough information.

We need more about the ODBC stages. Same data source? Same table? What are the transaction control settings? What is the update rule? Is it possible that the same key values might be found in both sources?

No.

Only entire key lookup is possible using a Hashed File stage.

"Too many" is not quantifiable; it depends on the complexity of processing and the size of the argument(s).

Warning

Too many levels of recursion will cause a memory error.

Don't run the command cat a b c > d as a filter. Instead, run it as a before-stage subroutine.

As Craig, said, filters don't work that way. If you want to use a filter, the command would be cat a b c and DataStage would use stdout from the cat command as its source of rows.

Also show us the schema, so that we can determine whether END_DT really is a subrecord or tagged record type.

DSLinkRowCount on the link servicing the database reports how many rows were sent successfully along that link.

You also need to capture whether any rows were not accepted by the database - standard reject handling in DataStage - by counting the number of rows on the reject link.

It depends. Given that one of your criteria is to use all the partitioning and parallelism available in server jobs, I'd be happy to assert that a highly competent server job developer could create a set of jobs that would finish more quickly than a set of parallel jobs created by a less competent d...

Create an explicit message handler if this warning concerns you.

Create a Routine that returns its input argument but logs a message if that value is zero. FUNCTION WarnIfZero(Arg1) If Unassigned(Arg1) Or IsNull(Arg1) Then Ans = @NULL End Else If Arg11 = 0 Then Call DSLogWarn("Zero value encountered in transformation.", "...

Because you are performing a lookup against a partial key or secondary key, it is possible that more than one row might be returned. The DB2 stage is not equipped to return multiple rows on a reference lookup, so generates the message. You have three choices. Use an ODBC stage, which does have multi...