DSXchange

It would seem your c compiler is not correctly installed. What happens when you execute "/opt/SUNWspro/bin/CC" from a UNIX shell?

A sequential file cannot have null values. You have two methods of doing this - in the attributes for the output column you can specify what value to use when a null is present for each column, or you can use a transform or modify stage to replace null values explicitly in each column.

If you re-installed the DataStage server, then created empty projects with the same names and absolute locations as before, then overwrote those directories from a restore you should have been able to see the jobs. If you attach to the directory from UNIX you should see a number of files - i.e. RT_B...

The loop mechanism doesn't cater for infinite loops. But I've written 'never ending' loops using the counted method and computed that this job would run for several years taking into account the typical loop execution times; so for all intents and purposes I felt confidant that the loop would never ...

If the "HashFileName" is ever an empty string you had better pray that you have a recent backup...

Take things step by step. If you do your StringToDecimal conversion and write the resultant decimal column to a PEEK stage, are your leading zeroes gone?

The c++ compiler is a separately priced component and is neither part of nor installed with DataStage. You can use the "whereis cpp" command to get the path to the cpp executable.

A Decimal column cannot/does not have leading zeroes. Could it be that your input is coming from a text file and is a string? In that case just one StringToDecimal() call is necessary.

How many nodes in your configuration file and have you specified a partitioning method?

I mean absolute paths for all the files, not just the script. Try the following - in UNIX, do a "cd /tmp" and then ":/prop/llb/tng/bin/ECS_SPLITTER/ECS_Employer_File_Splitter.sh" - my guess is you will get the same error.

Odds are that you are not specifying absolute paths for these files. The working directory when executed from a job is the project directory; so either use absolute paths for everything or put an explicit "cd" into your script.

shiv4003 - DSXChange is a supplement to the documentation and help files, not a replacement. In addition, the search function is very powerful and should be used before posting questions. In this case, searching for "DS.TOOLS" yielded 367 matches, so I see no need to explain DS.TOOLS once again.

mkdbfile will not be successful if it cannot create the file/directory (verify by testing with "touch" under the same id) or if the file exists already.

Since it only happens in one project, it isn't a client issue. You most likely have some sort of corruption in that project. Try using DS.TOOLS option 2 to see if that fixes the problem, but do a UNIX level backup of the project directory first in addition to a full export. If the DS.TOOLS doesn't f...

Do you have several projects? Does this happen for all projects?