DSXchange

Your original question did not mention grouping. Therefore I answered in the sense of a simple sum. You need sorted input and more stage variables to identify when the groups change so that you can reset the summation variable.

That is rarely necessary. It only governs how dates and times are handled.

I disagree. The simplest way is to add DISTINCT to the extraction query, as suggested earlier.

It will slow the job down immensely but it can be done. It's probably best to call your routine from a stage variable, so that you can discard the result. Write your routine using the C-language DataStage API; you probably need DSLogInfo() or DSLogWarn() somewhere within the code. See Parallel Job A...

Stage variable initialized to zero and added to as each row arrives on the input link.

Not available (use Remove Duplicates stage).
Not available (use Remove Duplicates stage).
Mean.

You would not call the shell program from the Transformer stage. You would more likely call it from a before-job subroutine, using ExecSH. But, as I indicated earlier, it is not necessary to incur the overhead of starting another shell.

Try using four or five Transformer stages, with four or five lookups each, and enable inter-process row buffering. That way you will have four or five separate processes each with its own memory allocation.

Add a reject-handling link to the Sequential File stage. It will capture the header and trailer rows because they do not match the record schema of a detail rows. These captured rows can then be re-parsed using, for example, a Column Input stage.

You don't "handle goto" in the Switch stage. You associate an output port number with each candidate value. That's all you have. Anything more complex you're probably going to need a Filter stage or Transformer stage.

Answer the questions that Havoc deigned not to.

How? We're not at your site. Further it looks like an internal error (given that what appears to be a memory address is included), so probably needs to be reported to your support provider. I'm guessing that the Designer editor (EditServ) has had a problem (saving?) the job definition. Is your job s...

A value from 0 to 6 that indicates your local convention for the first day of the week. For example in the USA a week begins on Monday, in Australia a week begins on Sunday.

Not at all. But the parameter markers are positional dependent upon position in your columns grid. Had you used generated SQL it would have found the Key column at #3 to include in the WHERE clause.