DSXchange

What sort of a job is it - a job sequence or a PX job? If it is a job sequence, then could it be trying to reset the job "work_cond" before running it and encountering a problem there (for example, that "work_cond" is not compiled)?

Using data sorted on the join keys is particularly fast and is also light on memory usage since only the data for a key grouping must be kept in memory during processing. Contrast that to the method needed for a lookup, where the complete lookup reference data is held in storage. I won't go into spa...

venugopal.123 wrote:Use field function to remove <> in the column...

I don't think that the field function is usable here. The FIELD() delimiter is a single character and not the 2-character sequence required here.

While I don't have access to DB2 for bulk loading, I would start with looking for log files and also posting the complete error message, which might be in a different director log entry. Also, does this error always happen at the same place in the process? Does it always happen? Has it ever worked a...

Craig has put it correctly, the real problem is that the OP did a DS.REINDEX while users were in the system, which corrupted the indices on DS_JOBS and caused the secondary error which was reported in this thread. 1. Only do a DS.REINDEX when no other DataStage users are in the system. 2. If you get...

The corrupt file is/was the log file for the job. Doing a "reset job log" from the director could clear that error, or by renaming the original and then doing a "save as" back to the original name and then recompiling.

No shell script will get you that information. An export from a client sesssion does not use scripts but is between DataStage server and client.

The important part is visible. Perform an explicit truncation or rounding if you wish to get rid of the warning, or write to a column that supports decimals.

If your target column is an integer then, as you suspected, the real number passed to it gets truncated. If you cannot make the target field contain decimals then I would explicitly perform the real -> integer conversion in DataStage and avoid the error. You can either round or truncate.

DataStage does not store information about job exports in the repository. The job modification information is stored in the DS_AUDIT hashed file. This file is not documented, but there are several threads here on DSXchange which give information on the layout and use; This thread gives some insight.

I don't know the correct C++ compiler that DataStage requires, it is specified in the documentation and installation instructions. If you don't have 7.5x2 then you will be able to compile, but not run PX jobs. When you compile you will get an error message, if you view the details and then paste the...

Exactyl what version of DataStage do you have installed, as only 7.5x2 can actually run PX jobs. Also, please post your compilation error and also your runtime error; without those we would just be guessing as to your problem.

I wonder if the file access is set to be read-only for the userid who edited the file in the Administrator and the write back to the DSParams failed but didn't produce an error message.
After making the change from the Administrator, check the date-time-modified on the DSParams file - has it changed?

Assuming you aren't getting runtime warnings, if you do a "View Data" in the designer, does the first line get show? If yes, then most likely you are dropping that line somewhere in your job. Addition (I just saw your 2nd post after writing my response) The likely reason is that you are re...

My guess is that the column definition for TRIP_NAME_IDENTIFIER is incorrect, perhaps a numeric type, while the contents are a string (either that, or your first line contains column names)