DSXchange

The process table to which I referred is the UNIX process table. A process ID is a row number in this table. It is internal to the UNIX kernel.

If they are all in one Transformer stage select them all, right click and use Derivation Substitution to enter the transformation expression once.

If they are in separate Transformer stages the answer is no, but you still have copy-and-paste available.

Behaviour is different if there are duplicates on the inputs. In a Merge stage rows are consumed from the Update inputs.

I do this sometimes to sort by Status and bring all the Aborted jobs to the top (or all Running jobs).

Then I re-enable Categories.

Are the correct number of decimals appearing in the DAT file?

The biggest issue is that the UniVerse database is not distributed, therefore can not be accessed from any processing node that is not also the conductor node. If you restrict the stage to execute only on the machine where UniVerse is installed, then there are several ways that you could access hash...

ArndW wrote:I suspect that UniVerse can still access DataStage hashed files.

Only if there are no I-types and no indexes involved. Otherwise the magic numbers do not match and access is impossible.

These environment variables need to specify the location where YOU installed the compiler.

Try selecting a Table Definition and running a Usage Analysis on that.
It will show the jobs that reference any column(s) in that table definition.

You might also try selecting a Job that you know is invoked from a job sequence.

Any term: "source" "target" "input" "output" "table"

You don't. DataStage connects to the database that stores data used by the PeopleSoft application.

What you need is the metadata for those tables. The easiest way to get those is via the PeopleSoft PACK (from PeopleSoft in the form of "canned" DataStage jobs, table definitions and routines).

It never matches with row buffering off because (a) both Transformer stages are in the same process and (b) row counts are only updated periodically (you can see that by inspecting the generated source code).

If there are only fully-additive facts (sum, count, min or max) in the aggregate table you can maintain it while inserting rows into the detail table (that is, from the same DataStage job or using some mechanism - such as a trigger or a stored procedure - within Oracle).