DSXchange

Memory allocation and resource management is part of the underlying operating system, not DataStage. How are you measuring your memory usage? If it is using different amounts of storage on subsequent runs then it is your data (either source or interim) that is causing that change, not something with...

If you run the job with just 1 row input do you get 3 rows output? This will make your debugging a lot easier. Also, what are you doing in the aggregator stage?

AS far as I recall, the FTP stage takes a hostname and then a path, there are no URLs used. Just specify your host/user/password where listed and use a normal path to the file.

Even though I don't do it, the ABORT can be kept in the routine, as the DSLogFatal should never return. But when testing the routine from the manager the execution is not part of a job and thus the DSLogFatal() call will return and then the ABORT will kick in. But the original poster (OP) still need...

The DS/BASIC "ABORT" function without an expression should not be used in DataStage, it will terminate a job immediately, unlike the DSLogFatal() which will not only abort the job but update the job run information and perform other cleanup tasks

What DataBase running on what Hardware and OS? 100 connections to a SQL-Server running on a 300MHz Pentium might be too much, but 100 connections to a DB/2 EEE running on a 32-CPU P-Series might barely cause a ripple.

1. You must include the line "$INCLUDE DSINCLUDE JOBCONTROL.H"
2. You will need to fill the values for StageName and LinkName to get values returned to you. {amended, added $INCLUDE to text}

DSLogFatal() will stop the job from running and update the log file. DSStopJob() will issue a stop request, and if the job gets stopped then it will also have a status of aborted in the log.

Then put your ORDER BY into your Oracle SELECT statement.

To add to what Roy has written: DSLogFatal() will stop the current job with a fatal error code and message to the log file. DSStopJob() will issue a job stop request to the job whose JobHandle is passed to the routine. If a job hits the DSLogFatal() call it will stop and will not return. If the code...

Installing multiple instances will probably not help you, since each one does use shared memory and have it's own rpcdaemon running the "footprint" would be a bit larger. Ascential has also stated that they would prefer not to have several engines running and depending upon your licensing scheme it ...

If you want the information from inside the job, the transform stage variables @INROWNUM and @OUTROWNUM will work per instance. If you want the information from outside of the job, you can use a routine such as DSGetLinkInfo() or use the UNIX command line "dsjob -report" to get that data.

Stylesheets are an element of XML files and are not really part of the scope of DataStage. Whole books have been written about stylesheets and a Google search for "XML Stylesheet definition" returned over 2 million hits while Yahoo! brought back 1.9 million, which should be enough for you to find ju...

A DataStage project as such doesn't use up any CPU time. The limitations will come on concurrent job runs, regardless of how many projects they are spread across. I am assuming that you only have one engine running in this configuration - otherwise it does get a bit more complicated. The only real r...

The SIGSEGV signal is indicative of an error, but you need to supply a lot more information before it can be diagnosed. Does the error occur when deleting only a couple of hundred rows? Does it always appear with the row? If you go to a single node configuration file do you have the same problem?