DSXchange

It's a function of row size; effectively it's how many rows of data to move in one hit, for example to make best use of internal buffers, network packets, and so on. It's only an exact science if you know the exact and unvarying values of every possible variable in the mix (which you don't and can't).

Yes, I missed the "multiple inputs" part of your requirements. The problem now is that you do not know which link will fire first. If you do, check "clear file before writing on that link". Otherwise, you need to use the CLEAR.FILE command (or its operating system equivalent for pathed hashed files)...

The DataStage Repository is a database in its own right, and uses row-level locking to ensure that two developers cannot simultaneously open the same object. Indeed, you can not even open a job design if that job is being monitored (protection against the chance that any design change might invalida...

What if you set your rows per commit to 1 and your array size to 1?

Perhaps
"R2%11" is another way to write "11'0'R2".

You may indeed find that binaries for all UNIXes are on the one CD, and that the actual operating system is embedded in the auth code so that the installer knows which binaries to copy. It's been a while since I looked at one!
This would make everyone correct! (Even though not useful.)

It's become less clear to which locks you are referring. Is it locks in the source/target databases (which should be released by abort processing in DataStage, according to the API specification for writing plug-in stages), or is it locks in the DataStage Repository and, if so, which ones? This, too...

So, in DataStage you're generating the "dynamic SQL" for every row processed, while in PL/SQL (presumably) you're not. Is this the case? And you expect it to run at the same speed! Read my earlier post again. I don't think you have much scope for improving performance without moving away from a "dyn...

Not without seeing the code for the routine! :D Somewhere in that code there is a path through the code that allows a variable (perhaps Ans) not to be assigned a value before that variable is used. There is no workaround. It must be fixed . If it's not too sensitive, post the routine code here, and ...

Does anything get written to the output file at all? Near the beginning of the routine add the following calls: Call DSLogInfo("Value of infilename is " : Quote(infilename), "*Debug*") Call DSLogInfo("Value of outfilename is " : Quote(outfilename...

There are many reasons a write to a hashed file might fail. You can search the Forum for some of them, which include operating system permissions, file full (there is a 2GB limit by default, but in this case you would not get warnings for the first 2GB worth of records), disk quota exceeded, file co...

Buildops are used to create custom transformations. You can use them wherever you need to perform a transformation. There is a Chapter about buildops in the Parallel Job Developer's Guide , which is installed with your DataStage manual set (on your DataStage client, for example C:\Program Files\Asce...

Why don't you do it in a proper (that is, DataStage BASIC) server routine? GMT is easy to do, provided your TZ environment variable is set (which a C routine would require in any case). Is it a time in your data, or just the system time, that you need to convert? Take a look in the SDK routines; the...

Buildops are used to create custom transformations. You can use them wherever you need to perform a transformation. There is a Chapter about buildops in the Parallel Job Developer's Guide , which is installed with your DataStage manual set (on your DataStage client, for example C:\Program Files\Asce...

Anything that requires sequential file I/O is limited by the operating system to a single writing process. (This is not a DataStage limitation.) The warning is issued to alert you to the fact that your design may introduce a processing bottleneck.