DSXchange

As a general rule anything with "lib" in its name or with a suffix of ".so" needs to have itself (lib) or its parent directory (".so") in the shared library search path (LD_LIBRARY_PATH, SHLIB_PATH or LIBPATH environment variable, depending on your flavour of UNIX). The order of directories in this ...

If the input column is a string, then there is no implicit conversion to decimal. You need decimal_from_string() function.

I can not see a UniVerse stage in the job design you documented, am I missing something?

The usual, and officially documented, approach to get link names is to invoke the DSGetStageInfo() function in a routine.

To quote a certain advertisement, "just do it". Determine that no rows were loaded (how you do that depends on several factors, but do not believe that it's the same thing as the number of rows DataStage sent to the table). To send email either call DSSendMail() in an after-job subroutine or use a N...

Sounds like the project may need re-indexing (using DS.REINDEX ALL next time you can get exclusive access to the project).

There shouldn't be. Why might you believe that there is?

You don't. You make $DBPWD itself the job parameter.

A Sequential File stage always allows Null Field Value to be edited provided, of course, that the field is marked as Nullable.

Try putting the name of the table you are querying into the Partition Table field as well, to see whether parallel execution becomes available.

DataStage Installation and Upgrade Guide page 3-2 has the "official" story.

The repository database has not been UniVerse since DataStage version 5.2, it is now (in version 7) a derivative thereof called DataStage Engine.

Things change again in version 8.

Don't believe there is. Happy to learn of course.

chulett wrote:We can usually get you on the right / much more better road to take you to your goal once we know what that is.

This may involve the MMB stage (an invention of Craig's).

DSJobStartTimestamp is NOT a variable - it's a macro that invokes DSGetJobInfo(DSJ.ME, DSJ.JOBSTARTTIMESTAMP)

Evaluating this for every row could certainly be expected to increase overall execution time.

If you want to search for "valid date" it's a slightly different approach. Use something like