DSXchange

Have you done a force recompile of the job?

If you were to use a "LIST" instead of a "SELECT" the previous advice would have helped and you would get more assistance on any other errors. What does "LIST HashOther" or "LIST DICT HashOther" produce?

With DataSets the actual disk space used for an unbounded Varchar column is smaller than that used in a bounded one.

This internal metadata information is not documented, and I wasn't aware that Infa did that, either. Quite a bit of the internal structure can be seen by looking at the .xml export of a know job but that is all the help that you will get.

IsValid() is the correct route to take. What isn't working with that function?

The SIGIOT is the same as SIGABRT. That probably doesn't help you much, though.
If you check the config file or a dataset from UNIX (i.e. try "orchadmin check") do you get the same error message? Do you get the error when designing/compiling or just execution? Have you tried restarting DataStage?

One could try to do this with a 7.5x2 client & 7.5x2 Server combination, export the job and "fudge" the version number in order to try to import it at 7.5.1 but I wouldn't trust this method not to cause a problem.

Far better to use the (free) multi-client manager.

Sunroy68 - you aren't changing the compiler, just the "compiler options". Depending upon your platform, the standard options will contain something reading "-O" or "-o" and that defaults to some level of optimization. Changing that to "-O0" or "-o0" turns off optimization.

Fixed what, Craig (I love revisionist history)

That points to a repository type error, perhaps due to locking or a corrupt job. Can you do a "save as" of your job and then drop/add the parameters without a problem?

dsd682 - a lot of people here are those conducting technical interviews. Many here, including myself, consider giving out answers to such interview questions to be counterproductive - "cheating", as it were; and certainly won't give out advice of this type. It is much better to tell the truth that y...

Is there any regularity to the failures? Time of day or number of iterations or the like?

The first or second entry in the job log shows the parameter values that are actually used in the job run. Are those values filled correctly or are they not?

The c++ compiler optimization chews up large amounts of resources. For typical transform stage functionality the compiler's optimization won't bring that much performance improvement, so turning off or lowering the optimization level is acceptable.

Ignore the other errors, the abort is due to memory. I have had to turn off optimization in large transform stages before.