DSXchange

Error code 52380 has been generated by the ODBC Driver Manager. I think you now need to research via Google or Data Direct to find out what that code means.

How are you determining the number of rows in the Data Set?

What else is happening in the job design? Is there anything at all in the job design that might prevent records from being passed through? Is the job compiled in trace mode?

Apply Ockham's Razor - your "solution" is way too complex. Just use an inbuilt integer-to-string conversion function.

Only a small amount of thought will explain why hash partitioning on the column(s) in the WHERE clause is the solution, and why not having it might cause a deadlock, particularly if rows/transaction > 1.

So please think about it.

G SHIVARANJANI wrote:Am i not clear enough

No, you're just impatient. Your two posts were only an hour apart - for me they came in at 2am and 3am.

If you want me to respond at that kind of hour it will cost you MEGABUCKS!!!

That is not how you create a File Set control file. The only valid way to create a File Set is to use a File Set stage with an input link.

Similar assertions apply to Data Set and to Lookup File Set.

One customer is running on a grid of 400 Linux machines. DataStage EE is totally scalable. They're very happy with it, not least with the low hardware cost.

Type in oerr ORA 3113 to find out other possible remedies. Involve your Oracle DBA and network administrator. Increasing rows/transaction is not likely to make much difference if the problem is network dropouts.

Possibly beause there was a null in one of the key columns attempted to be written to the hashed file.

Hashed file, not hash file.

Easiest is to have the jobs themselves add records to a central table.

Depending on your auto-purge settings, DataStage may not be able to provide the requisite information.

No.

No hashed file can exceed 2GB without being created/resized to use 64-bit addressing internally. Increasing ulimit or a kernel file size parameter will have no impact whatsoever on existing or newly-created hashed files.

Fetal (foetal) is not the same as fecal (faecal) which is, I'm fairly sure, how you were thinking.

A third approach would be to use COMMON variables or system variables @USER0 through @USER4 - assign values to them in the before-job subroutine and access them within the job itself - in expressions or in routines (tranform functions).

Was 7.5 installed in a different location and program group than 6.0 ?

Did you re-start the Windows machine after this installation? Which version of DataStage starts?

Let me get this right in my head. For every row processed you are: deriving a stage variable invoking a routine invoking a DOS shell executing a BAT file recovering its exit status making a decision about aborting based on a constraint expression [Reject] Don't you think there might be too many laye...