DSXchange

It's actually 18 characters. This is so that the SQL Catalog for DataStage can be 100% compliant with a whole heap of standards, including SQL CAE Access Group and ODBC standards, that limit a schema name to 18 characters. The operating system is irrelevant. This is a limit within the SQL engine.

You can use the ODBC driver for text files. Just don't complain about the performance, which will be horrible.

Not possible using the Options button in the Hashed File stage. You need either to create them using the Hashed file stage then RESIZE to 64-bit, or to create them manually as 64-bit. For the latter you can copy the command from the Hashed File Calculator. <losing battle> It's HASHED file, not hash ...

Just after posting that I had another thought. DataStage does do one form of translation - localization. There are no text messages in DataStage code; everything has a code. That code is decoded using a "resource" file, for example DS_RESENU for English (US), DS_RESJPN for Japanese. These are hashed...

Be very careful. DataStage does NOT do translations. DataStage performs character mapping (it's not the same thing). The character set in which external data are encoded - for example GB2312, Shift-JIS, PC936 - is mapped to DataStage's UTF encoding of Unicode on the way in to DataStage, and back to ...

WaitForFile is one of the activities you can specify in a job sequence. You can wait for the file to appear, but also set a timeout so that, if the file has not appeared within that time, a different course of action may be triggered - maybe sending an email to someone who's paid to worry about thes...

Row buffering simply means that N rows at a time are passed between active stages / processes, rather than 1 row at a time. VarChars are stored (in server edition) as Arnd indicated, with a length indicator in the DATUM for each. From this, it follows that the Len() function is actually the most eff...

As Craig noted, VarChar values must be trimmed both when populating the hashed file and when performing the lookup. It's the only way you can be certain that you're "comparing apples with apples". This is the cause of the problem you report 95% of the time. The other 5% are that none of the values i...

None of which I'm aware. Searching the forum will uncover a routine that can export a Table Definition in a number of formats.

Try just putting the name of your script (that is, don't use ksh) into the Filter Command field, possibly with its three command line arguments. Each row will be passed through that script before ending up in the target file. That is, your script must be written to process its own stdin, on which ro...

Try it with the report_lic option explicitly specified.

Welcome aboard. :D

The answer to your question is NO.

Superuser (root) is always an Administrator for DataStage.

If you don't mind the warning messages, load it with a UV stage (which uses SQL) with the update rule "insert new rows only".

They are unrelated. Clear Status File destroys all status information relating to the job. It should only be used as a very last resort - that's why you get two "are you sure?" messages. Cleanup Resources is about processes and Repository database locks relating to executing DataStage jobs and conne...

You will find, by inspecting JOBCONTROL.H, that -8 means "not in stage"; typically, that DSGetStageInfo() or DSGetLinkInfo() was called using DSJ.ME for the stage name but you were not executing in a stage at the time. In your case you were executing in a Routine (in, or invoking, one of UtilityMess...