DSXchange

With a bit of work the actual statement that caused the failure can be found, but it is quicker to approach the problem from the other side. Is it just this table that is causing the problem? What data types are in this table?

At Version 7.x there will probably be no difference in performance due to how DS actually allocates IOs. This might be different at V8 but I haven't done any specific testing. During job execution monitor your Disk IO over your controllers and device and see if they are relatively well balanced; onc...

this is just a new name or branding from IBM, the product remains the same. The current main release of DataStage is 8.

Hmm, the status of 99 combined with multi-instance jobs... Do you have auto-purge settings for this job?

Look into one of the files, if it is an ASCII text file with what looks like record contents then you have a type 1 or 19 file (most likely 19 if the file names are long) - actually, that is what I should have asked - what are the file names? Do they bear any relation to the keys?

I don't know what the cause is, but seeing the word "type" would lead me to look at what Oracle data types you are using.

Assuming you have about 80000 records in the file I would say that you created the file as a type 1 or 19 file, where each "key" in the hashed file is a sequential file with the key as filename and the hashed file record contents get written to the file.

It might be that your system is overloaded during the startup phase. Have you monitored the system activity (CPU and memory)?

NLS always involves the settings on BOTH sides, so you need to know what map is being used in your database, then tell DataStage to output that set.

Note that "Philip Law" and "Mchen" are not part of any date system that I know of, so you would need to remove that part of the string prior to conversion.

I've done this conversion several times. The DataStage portion is the easiest part - your scripts are likely to cause you more conversion issues. The most efficient approach is as Craig has already suggested.

Going through ODBC to do a direct hashed file lookup is slow. Using partial keys is slow. Could you give an example of the partial 3 key lookups you are doing, as you might be able to create an index on the hashed file and use that directly for the looking or at least avoid full table scans when usi...

Reduce the number of nodes in your configuration file and/or sort your input data.

I am not at a DataStage client at the moment, but know that I have used Before/After job routines at Version several times in the past so they are still in the product. I would guess that the before/after routines in stages might refer to BASIC transform stages, though.

For the second time in this thread, it cannot be done in a transformer becuase you never know when the last row has arrived.