DSXchange

Call DSLogFatal is not available in a shell script. It is only available within the DataStage BASIC programming language, which only executes within the DataStage run machine. The same is true of $INCLUDE, though you've commented this out.

Exact use of staging tables? Staging.

Now put ExecSH into a before-job subroutine and execute ulimit -a from within a running job. See whether you get different results.

Not expected. After all the Pivot stage does not change the value - it only moves it to a different place. What happens if you change the output to unsigned BigInt (int64)?

Are you using a disk pool called "buffer"? How much of this 116GB is actually allocated (in the configuration file) to DataStage processing? The answer to your question is to mention more file systems in the configuration file.

Many ways. The easiest is to use a server job and put the values into the job's user status area. You can write them to a file and have the sequence job read the file. And so on.

There isn't any. No-one's hacked (or admitted to hacking) the unified metadata repository database yet.

You'll get an empty window if you don't have any breakpoints set.

I would really like to read your response. Could you please reply to the id divstands@yahoo.co.in as i am not a premium member and hence cannot view the response. Premium membership is one of the ways that the hosting and bandwidth costs of DSXchange are met. It's not expensive (less than 30c (Rs 1...

Can you please capture the report of link row counts for the Copy stage and post it?

Srimeenadevi wrote:Is this a space constraint in server.

Yes. Actually it's running out of space, so allocating more space will solve it.

Read the entire message carefully.

Nah. Horribly gruesome, as you admit. Much easier to check for the existence of the CHECKPOINT record. There is added complexity for multi-instance jobs, which each have a CHECKPOINT record. But viewing the RT_STATUSnnn hashed file will reveal the naming convention. The basis of the technique is: Jo...

Triggering the job is not real time. To get real time you need an always-running job that listens - maybe to an MQ series queue, maybe because it's been exposed as a web service using WISD components. What you propose is certainly feasible, but will incur job startup time, which may not be acceptabl...

Is the output field also BigInt, or only Integer or smaller? That would be the typical cause of an arithmetic overflow.

Which part of this statement is unclear?

arndw wrote:I'm not in a position to check and don't remember the details