DSXchange

Compile in trace mode (check box on job properties window). DataStage will generate precisely this report as the trace.

There is no lookahead logic possible unless you use two Transformer stages. You do the stage variable things in the first Transformer stage, pass all the results plus original source data to the downstream Transformer stage, and effect the comparison and calculations therein.

Spelling, among other things.

What do you mean by "updating on a non-key value"? Are you using user-defined SQL?

... unless NewFileName were the pathname of a directory.

No.

You can certainly use orchdbutil to view the record schema (or read the same directly from a schema file), but that does not get it into the DataStage Repository.

The reason, if you think about it, is obvious. Unlike DataStage clients, dsjob is not connected to any particular project; it's just out there in the operating system. So you have to inform it in which project the job in question resides. The same job name might exist in more than one project (for e...

Not a great deal of value for parallel jobs (this IS the parallel forum) where it's just as easy to throw a configuration file with more nodes into the mix.

Control whether job activity A executes with a preceding Nested Condition activity that checks A's finish time (extracted, perhaps, in an upstream Routine activity). If it's the same date as today, bypass job activity A. Routine ---> Nested Condition ------> Job A ------> | Any Sequencer ---> Job B ...

Simple economics: supply and demand. Either demand fewer resources or supply more. Definitely not "silly" in any sense. There IS a hardware solution.

Import the Stored Procedure definition into DataStage. This will give you the columns corresponding to its arguments.

Call the stored procedure (from an ODBC stage, etc., or from a Stored Procedure stage).

It's the technology that permits multiple versions of DataStage Engine to co-exist on one box. The "instance tag" referred to is the first three digits of shared memory keys, for example 0xadeca000 has an itag of "ade".

Not in version 7.5. Maybe in the next version.

Ultimately the reason is that multi-instance capability did not exist in version 1.0, and the default has never been changed.

My personal view is that enabling multi-instance unnecessarily introduces an unwanted level of complexity, even if it's only a small level.

The larger the SQL Server table, the longer updates take. Use the bulk loader to append new rows. The problem is not in DataStage.