DSXchange

DataStage has many possible ways and formats to import metadata. If you try Import -> Table Definitions in the Manager you will get a long list of acceptable formats to choose from.

The first step is always to figure out which component is slowing the overall process down, i.e. which one is the "bottleneck".

I thought it might be that the display buffer might have run out of space on the "***" from the compile but perhaps the error isn't in the tranform stage after all...

It means you have less actual data in the row than your DataStage format describes. Fix either the data or your metadata.

I took the easy way out - instead of attempting to explain I just recommended using the drop-down list of valid parameter names

Try making a copy of the job and removing the firt half of the derivations in that transform. Does it compile? If no - perhaps you have a full error message; if not repeat the copy but delete the second hafl of the derivations and repeat.

I've seen this before as well. Windows access can be nasty. Do you have the same problem with Windows-mapped drives as well (probably not). What sort of NFS mount is this?

Go back to your sequential file definition but use the drop-down button to paste your parameter name into the field - I think you have made a typographical error and mis-spelled your parameter name.

If you have Oracle ODBC configured you could try using that stage to see if you get success or a better error message. The "core" for the DataStage engine means it is likely in Oracle, as a bad transform stage would normally give a DS/Basic error location before coring out. If you have a savvy UNIX ...

0.4.8 of DataStage would be "DataS" with rounding, right?

Kumar - that would be a migration. But as well all know, sometimes when the marketing department says "100% compatible" they don't really mean that...

Don't trust the "view data" to correctly display the Chinese characters. Write the data to a text file and use a viewing tool that you know will display Chinese correctly.

Did I understand that this is a sporadic error that does not happen every time? Also, which database are you connecting to via ODBC?

Even though I'm not a Duke or a Ray I'll put something in here. Do a reset and see if the generated log entry is any help. A core dump in a transform stage usually means yuo didn something incorrectly that the compiler didn't detect. What are you doing apart from column 1:1 mapping?

But of all the changes I think that the disappearance of the Manager is among the more trivial and unimportant ones!
I would put the integration of IIS and the moving of many repository elements from the local hashed files to a SQL compliant database of the user's choice at the top of the list.