DSXchange

These are NOT the correct job status codes. The correct job status codes are to be found in the JOBCONTROL.H header file in the DSINCLUDE directory (or by searching DSXchange).

I have used a Peek stage in a job for debugging. It so happened that a large number(60000) of records was displayed in the job logs, and so used up a large area in the log folder. I would like to know where exactly the logs are being stored in the /dsadm path, so that I can delete them. I am aware ...

This is, of course, a new requirement. The change is trivial, involving an UPCASE function (you could also use an 'MCU' conversion). I have added an additional constraint on OLETYPE which, while strictly not necessary, will reduce the number of DS_JOBOBJECTS records examined. ../../DSEngine/bin/dssh...

The output from the Transformer stage can go anywhere. If you don't want to keep that row, use a Copy stage with no output. If you simply want it in the job log, use a Peek stage. If you really want the row in a file, use a Sequential File stage. A Data Set is overkill for one row.

In case: (a) the project default is different in production/test/development (which it is likely to be), and (b) you want - for example for unit testing purposes - to run once using a different configuration.

This is not DataStage at all, but rather your database server. Ask your DBA about how PSTEMP tablespace is configured, and perhaps to allow automatic expansion. A bribe may be required.

Welcome aboard. Speed is not the issue here. Being systematic and accurate is. DataStage needs to check that you really want to delete the job even though other jobs (and, perhaps, routines) might depend on it. If you want to be totally arrogant you can disable these confirmations. But let me state ...

The proper answer to this question would take about five days (the duration of a "UniVerse Internals" class) which I do not propose to do. DMEMOFF, PMEMOFF etc relate to shared memory segments used by the DataStage Server Engine. They are set in the uvconfig file. LDR_CNTRL is an environment variabl...

Welcome aboard. The first thing you need to do is to disable operator combination (at least temporarily) so that you can determine which operator (stage) is generating the error. Do this by introducing the environment variable APT_DISABLE_COMBINATION into your job as a job parameter, and set its val...

Welcome aboard. ODBC protocols require dates to be in YYYY-MM-DD format (according to the ISO 8601 standard). This requirement overrides the Oracle date picture and the actual format of your date. Change your date format, for example using Oconv(Iconv(InLink.MyDate, "DMDY"), &q...

Double quotes within double quotes (the "@RECORD" in the EVAL clause) is the problem here. Try using single quotes around @RECORD since the SQL statement itself is already within double quotes. ../../DSEngine/bin/dssh "SELECT NAME FMT '35L', CATEGORY FMT '35L' FROM DS_JOBS WHERE JOBNO IN (S...

Copy stage is cheapest.

${DSHOME}/../PXEngine/bin

A Pivot stage will not help your requirement.

The SQL query is syntactically valid. Please show us how you are trying to use it from the shell script.