DSXchange

If the exponent is integer and small you might be able to multiply in a loop.

If the exponent is integer and small you might be able to multiply in a loop.

The temporary table with keys is probably the best suggestion. Despite the large number of rows, being a key-only table means that it won't consume a lot of space, and the DBA won't mind you're having it. For example if you had a single integer key, the table would require less than 0.3MB.

Only table structures are imported, and then they're largely ignored while the analyses look at actual data (what's really there, as opposed to what the metadata claim). Usually the sample is created during the Column Analysis phase. Can you review your work there - even reset so that the Column Ana...

Can you verify where the sample data are stored? What are the row counts (sample size) for the sample in the PSDB?

Reset the job in Director and report back whether any "from previous run" message is logged and, if so, its contents.

I am assuming here that your job name is "sample" and there is a Transformer stage called T1. Further, the job is not running as a multi-instance job.

If you're running version 7.5x2 of DataStage you DO have MKS Toolkit - it installs with DataStage. So you can use UNIX-style shell scripts.

You can use .nextval in user-defined insert SQL (which is what I think you may also be asking) but the same single-threading will apply, which somewhat counteracts your use of multi-instance jobs - or even parallel jobs, for that matter

While we think about this, can you please put yourself in the position of DataStage - doing simultaneous inserts from multiple processes all of which have to generate unique values of the same column. How would you do it? Essentially that's the same way that DataStage would have to do it.

Are you running jobs under control of a job sequence, job control routine or batch? If so, is there anything else logged for the controller and/or for the controlled job? If you Reset the jobs in Director, is there a message logged "from previous run..." containing extra diagnostic information?

Yeah, well...

Maybe seeing "don't use FTP stage" explicitly stated may stimulate a synapse or two.

Don't use the FTP stage.
Create a script to perform the FTP operation (in binary mode).
Now you have the zipped file on your DataStage machine, you can use gunzip as a filter command in a Sequential File stage.

Pedantically you can TRIM a CHAR data type, and it is immedately padded again with APT_STRING_PADCHAR (automatically, because its data type is CHAR).

The effect is the same.

Not possible in a derivation or constraint expression, which yours appears to be.

It is possible in a routine, but yours does not have the form of a set of nested IF statements (containing assignment statements) that one would expect to find in a routine.