DSXchange

The "," comma is the decimal separator in several NLS locales so you are correct and I was wrong - it is likely to do with NLS after all. What Locale do you have set - in German, for example, the default decimal separator is the "," character. Also, in the "edit row" at...

The "Not enough space" message almost always refers to disk space. I have fought with this issue before. After intensive checking during runtime it became clear that we had no disk issues, but that the lookup stage we were using tried to allocate more than 512 Mb. The solution is to use &q...

Also, which stage are you using to do this?

No, this has nothing to do with NLS. Perhaps there are "hidden" characters in the string and I seem to recall that spaces cause issues as well. Do the explicit conversion in a modify or transform stage and you can also implement the IsValid() function to check on validity.

That problem sounds familiar, I know I have had that once but cannot recall what caused it. You could try "dsjob -mode NORMAL -run Myproject MyJob" from the command line. If possible, do a restart of datastage. I think that is what I did when I had this problem.

In the first sequence you would program the filename as a parameter. Then execute a shell - I can't recall the UNIX file test syntax, but here's something else - "wc -l " as command, "#FileParameter#" as the parameters. Then in the condition part of the stage check for a return v...

When you reset the job from the director, do you get a log entry "from previous run..."? If so, what does it contain? From UNIX, see how many processes with the userid you use to run your jobs are actually running ("ps -ef | grep {userid} | wc -l")

Write a sequence which calls a unix shell to test for existence of said file. Depending upon the result of that test, call up the real sequence.

do a "reset" on your job and then look at the entry "from previous run...". Most likely your before job code (perhaps the job control) is calling things that don't exist or haven't been loaded into the new environment.

When you call a multiinstance job from a job sequence there is an entry field for the instance, you can put in a constant string or use a variable for the instance name/number.

Are you checking to understand an existing job or creating something new? If the incoming file is in DOS format you have a <cr><lf> as a terminator. If the file is fixed width you don't need line terminators.

If you are on AIX then this thread will help solve the problem. I thought that the solution was in another thread, with some more details, but couldn't find it. I think that if the lookup exceeds 512Mb you get this error unless extended the space. Note that if you have large VarChar columns in the l...

I assume your input file is bigger than 100,000 rows. Isn't doing several runs, each processing 100,000 [different] rows to separate output files the same as doing one run and then splitting the output into chunks of 100,000? The latter would be so much easier and less susceptible to errors.

"alter login xmeta enable;" might do the trick.

Is it an ORACLE repository? If yes, the DBA should do an "alter user xmeta account unlock;". But you will need to find out who is trying to login with the wrong password since that error is bound to occur again.