DSXchange

I'm not at a client now, but don't you get errors or warning messages through the parallel job sequential stage for the middle 2 records? You could automatically drop those or aboend the stage.

What do you consider a "special" character?

Normally I'd say "sed" or "tr".

The filename for an output file must be either a constant or a parameter (or other variable or combination of types). Parameter values cannot be changed within a job, so you need to determine the filename through column values in a prior job, then pass that value to your job as a parameter. How you ...

OK, keep with one node, it makes debugging easier.

How many columns are you using for your joining key?

If you keep your join key columns and just one column from the left and right link to your output (which should be a "peek" stage), does the error still remain?

In the drop-down list "available properties to add" where you select the "max" value, you can (and should) also choose "preserve type"

Does the error still occur when you run the job in 1 node?

The results of one lookup cannot be used as values for another lookup within one lookup stage, you would need to use 2 stages in order to do that.

The "bitexpand" isn't inside DataStage, is it?

Only the first part of the message, "Internal Error: (minIndex < m_outputLinkObjArraySize): pxbridge.C: 3741 " is important. I don't think a simple solution is available to describe the problem. You will have to do the iterative process of finding the cause. Is there anything in particular...

First I'd convert the Char(1) to a number using "Seq(In.Column)". Now it is a simple loop to convert this to a string of 1's and 0's. Which version of DS do you have, i.e. can you loop in transform stages? If not, then you might have to write a simple c++ function to do this. Alternatively...

What are your sequential file settings?
Also, since you are on unix, do an "od -x <file>" to see what the ascii code of the character in question really is, it might be an 0x00

$APT_PM_SHOW_PIDS, $OSH_DUMP, $OSH_ECHO can be used. Basically, all of the entries in the "reporting" category of the parameter list can be turned to to see if it helps narrow down the error.

In the DB2 Connector stage in the top third, right-hand side, you have a drop-down box which lets you choose the lookup type.

In the DB2 Enterprise stage in the link source -> Lookup Type you can select a "sparse" type lookup.

I tested it, and it fails. I don't have any docs to check whether this is expected behaviour or not, but I don't believe it is.

It would seem that will correctly convert, while won't.