DSXchange

Create a Routine that attempts to open the file as if it were a record in a table, relying on the fact that DataStage BASIC can treat the folder as a table. For example: FUNCTION FileExists(ThePathname) * Returns 1 (= true) if file exists, 0 (= false) otherwise. OpenPath(...

You can use a job parameter set in a controlling job. The controlling job (or job sequence) would generate the file name, perhaps using a Routine, then set a parameter containing that file name that the real job could use. If you were writing your own controlling job, it would look something like th...

This is splendidly explained in the manual for the Pivot stage (pivot.pdf).
You can also find it by searching this Forum, for example here.

DataStage jobs run as background processes on the server machine, which may or may not be the same machine as the one on which your Director client is running. Background processes do not have any "terminal". Therefore they have nowhere to display forms. I guess you could use Windows commands such a...

Another mechanism is "global catalog". Here you use a leading asterisk in the name: CATALOG DSU_BP *SecureRoutine In all projects that have to access this, you no longer choose transform function as the routine type. Instead, you choose "custom UniVerse function". Find CATALOG in the DataStage BASIC...

None of the previous posts is completely correct, as the answer depends on whether you're referring to the internal storage model (in which case the best answer is "you don't need to know") or the structure of the record after you've read it (using a READ statement or one of its variants) and also, ...

Technically what Craig says is correct. If you append, or prepend, something unknown, then the result is necessarily unknown. You need to convert the null to "" or 0, depending on the underlying data type. There are SDK Transforms for doing exactly this. DataStage does, however, let you concatenate ...

One input parameter means you must deliver one column from the input link.

The same number of columns as are defined on the Columns grid on that link of the ODBC stage. When you import the Stored Procedure definition it is filed within the Table Definitions branch of the Repository, so you can see how many columns it expects to be in the Columns grid.

Director doesn't run on UNIX; you'd need to dial in to a Windows machine to do this. Once you're logged in (presumably via RAS), you're just another Windows user; connecting via Director (or any of the other DataStage clients) to the DataStage server is as usual. Similarly, if you're set up to dial ...

Only indirectly. You need to do it in job control code, in which you build all parameters before issuing job run requests. hJob1 = DSAttachJob("Job1", DSJ.ERRNONE) ErrCode = DSSetParam(hJob1, "SRC", "dev") hJob2 = DSAttachJob("Job2", DSJ.ER...

There is, in Routines\Built-In\Utilities, a routine called DSSendMailTester, which contains sample code to allow you to research how to invoke the DSSendMail() function correctly, and to test it.

DATE.TAG has been around for a long time. It simply performs Oconv(%Arg1%, "D-YMD[4,2,2]"), so should not have any side effects. So this is very odd behaviour indeed. Is it reproducible? If so take a look at the generated Transformer stage code (in the RT_BPnnn directory, where nnn is your job numbe...

Welcome aboard! :D The := is one of three "special assignment operators". The others are += and -=, for details see the DataStage BASIC manual, page 2-21 (or just search for := once you have the manual open). X := " LTD" is functionally equivalent to X = X : " LTD" , but executes more efficiently. A...

It gets really ugly if the table names are job parameters!