DSXchange

The dataset will be read and repartitioned according to whatever method you declare in your job.

[edit]
I was curious as to what would happen so I tested it.

Look again, the character after the carat is always an uppercase O in the sample you provided.

You need to do a "dbx $DSHOME/bin/uvsh core" but the dbx environment is complex and there is little you can see while debugging without knowing what you are looking for. I recommend you use the help facility and do a stack trace and see if the stack element names give you a clue as to what...

In order to analyze the core you need to understand how an executable program is built together and how runtime memory allocation and processing functions. The dbx program is usually used to do this (it is free with UNIX but not always installed) along with the actual executable that cause the core....

You are seeing a "^O" displayed. I don't know which tool you are using, but it could be ASCII 15. The value has probably been introduced during the move from the AS400 system.

For string fields add "EMPTY" as the value in the null handling section of the "edit row" for that each column.

You need to enter the credentials for the UNIX userid and corresponding password in that space (and don't check the box - I can't remember what the exact text is, but it is something about pooling or sharing the server's user information).

You need to have DataStage do something to columns with null values prior to writing them to a sequential file. I use the "edit row" and then set the null attributes for each column to do this.

Does the same error occur if you try to add project "TestProj" in "/tmp" (a new project name and a location where everyone can write)? Could it be that you don't have access to the UV_SCHEMA hashed file or that it is broken? Do you know how to enter TCL?

I'll chime in as well - don't delete the .ds files with "rm". You can cd to your directory with dataset descriptors and issue if you'd rather not do an explicit loop.

Yes "dsenv" file is in the $DSHOME directory, if that environment is not set, you can cd to it with "cd `cat /.dshome`"

Since shell scripts generally don't cause core dumps, the error is elsewhere. Please post the complete message and your command line as well.

Any running clients (director or designer) will have this file open.

Ahh, that changes things a lot. In the webconsole, did you go into Administration -> Domain Management -> DataStage Credentials; choose your server and enter the default credentials (correctly)? This is where the incorrect userid/password combination is most likely coming from.

AFAIK is As Far As I Know.