DSXchange

Check the format tab again. Make sure that the delimiter is comma. Then check the stage properties, and make sure that the line terminator is properly specified. Re-import the table definition if necessary, and click Load on both the Format and Columns tabs to resynchronize things.

The space is for the sign. For example, -3.3 and +3.5 are valid decimal numbers, as is 3.2.

Not "best", essential. If you don't have exclusive access to the project, the reindexing process will invalidate the indexes, but not be able to rebuild them successfully.

Other users can be using other projects, but you MUST have exclusive access to any project you are re-indexing.

It's part of DataStage, but separately licensed. So you need to buy it from your vendor.

"Stopped by operator" is not a status that is amenable to restart. You need to cause one of the jobs to abort - not the same as being stopped. Feed it some duff data.

Define "match by 75%". Sounds like the kind of probabilistic match that QualityStage (perhaps invoked through a QualityStage plug-in stage in your DataStage job) is ideally suited to do.

Source code is provided for all SDK routines. Examine the source code yourself.

How do the configuration files differ between the two servers? Did you ever run in a multi-node configuration in the development environment?

There is only one reason for import failure when using a Sequential File stage. That reason is that the row does not match the record schema specified for the stage's output link. The remaining diagnosis is up to you - the single column on the reject link is a Raw string (VarBinary). You can view it...

"Phantom" is DataStage terminology for "background process". You can trace the history of this usage back through UniVerse, Prime INFORMATION, PRIMOS, back to Pick O/S. "Zombie" is a UNIX term, describing a process - typically a background process - that is prevented from being killed (or even from ...

Ultramundane makes a good point. But "it's not good practice" is not the reason for splitting extraction from the other phases; there is a good reason (limited time window) in that case. I still believe that it's the right thing to do to challenge these vague assertions. Be like a young, wide-eyed c...

We also don't know what version of DataStage you are using. "They" made some performance improvements in the Transformer stage at, I believe, version 7.5.1A.

I can't see how you can have a "Problem with the Sequencer". All a Sequencer does is make an "any or all" decision as to whether its inputs have fired.

The term you wanted was Job Sequence.

DSRunJob() function can not be used in the way proposed. However there is an SDK function called UtilityRunJob() that can be so used.

But do you really want to run a DataStage job for each row processed by your main job?

If so, do not complain about rows/sec. It will be abominable.

Data source is specified as mainframe, we assume pushed to your DataStage server machine. Server jobs have no internal data types, so within the job the decimal number is simply a string of characters. That is why all you need to do is specify it as VarChar on the output link of a Transformer stage ...