DSXchange

Get your partitioning done as early as possible in the job.

1. Simply pass the invocation ID as a parameter (as well as appearing as part of the job name). If this job is being called from a multi-instance sequence, then the sequence's invocation ID can be obtained via a DS macro or Routine activity. 2. Yes. But are your DataStage BASIC programming skills up...

Write the output to a file. Use an Execute Command activity to read the file and translate the line terminators to delimiters such as commas that the StartLoop activity can use. Ideally strip the final (empty) line too in the Execute Command activity. The command output becomes the delimited string ...

Give something other that "TZD" as the timezone designator?

Obviously this is not a DataStage problem.

If you're going to anticipate a career in data quality, then you will need to learn to be more careful. This is not the first time you've "missed" the job type.

You also click Finish to begin saving an "import from CSV" in FastTrack, at least in version 8.7.

There is no uvodbc.ini and there is a .odbc.ini. That's the main difference. Assuming that you mean uvodbc.config, then the two files both exist and have different but complementary roles to play. .odbc.ini is used for defining ODBC data source names (and specifies Data Direct or other drivers) uvod...

Maybe it's because DB2 has UTF-8 enabled and DataStage does not. That shouldn't cause any difficulty (the other way would) but perhaps DataStage generates the alert for *any* mismatch.

In the link properties, usually accessed from the Output tab of the upstream stage.

Shared containers do not support (and never have supported) environment variable parameters. They only have string and encrypted parameter types. The job in which the shared container is used can have environment variable parameters, and these can be linked to string or encrypted parameters of the c...

There is an optional property called something like "source file name column".

It's perfectly clear.

The next higher whole multiple of 3 than the generated value is required.

Divide by 3, use the Ceil() function to get the next higher integer, then multiply that by 3.

(You could use round_inf, too, if you had some other conversion function that needed to be applied.)

Interesting (?) historical fact: version 1.0 of the ORABULK stage was written as an active stage (even though data-source-facing stages were meant to be passive) so that it could support before/after subroutines; one could employ an after-stage subroutine to use ExecSH (or ExecDOS) to invoke sqlldr,...

A is "discard new records" and, by implication, keep the existing schema.
B does not keep the existing schema.

On that basis is it not reasonable to assume that a new schema will be used, so that differently-constructed records might be stored?

Again, use WaitForFile activity. Loop on a SLEEP command. When the file is found, read it. Capture the output via an activity variable and determine your downstream logic accordingly.