DSXchange

You might try returning \x80, which is the standard DataStage internal representation of null, unless you are using a character set in which the euro character takes this code point.

In that case, check with the uvconfig file to determine how null is to be represented (for example \xa4).

Welcome aboard.

Wait for "Ernie the XML expert" to come along. :D

The numbers you get in DataStage Designer/Director represent the number of rows sent to the database by DataStage; they do not necessarily reflect the number of rows actually accepted by the database server. You should have at least one warning in the job log if there any problems. You can design yo...

PROBABLY your DataStage server (Connector, whatever) is pointed to a database different from the one you're inspecting manually.

Server jobs can also be run with a row limit, looks like these have been set for the OP's project. The solution is to set these values to 0 ( = no limit ).

Parallel jobs can also be row limited if compiled in trace mode.

I will miss both our forum-based and our private interchanges. I only met Kim a couple of times (since I'm usually on the other side of the planet), but those were always rewarding times. Vale Kim.

Same for me at the moment, working with a bank-issued laptop.

Next gig is with Defence, so I don't expect much difference there either.

There exists a C-callable version of the DataStage API, fully documented in the Programmer's Guide.

-param ParameterSetName=value Here, value is the name of a Values File associated with the Parameter Set. To have the Parameter Set use its "as defined" values, do not specify it in the dsjob command. -param ParameterSetName.ParameterName=value Here, value is the actual value with which t...

You are misinterpreting the effect of the left outer join.

Check your DataStage roles in that project. Operator role (the default) is very limited in what it can see.

Yes. You don't want to remove duplicates. The Row Generator has to generate all possible values. The left outer join will generate the requisite nulls.

If the source is a file, there may be a Byte Order Mark at the beginning of the file. If not there is no easy way to check the byte order, but you could try converting the file using dos2unix or unix2dos command, as appropriate, and determining whether the result is more sensible.

Thank you for contributing. The status of this thread suggests that it was resolved in 2007.

stuartjvnorton wrote:WoW?
Isn't that taken already?

Sometimes three letter acronyms (TLAs) have to be used over again (UOA).