DSXchange

All string columns are ideally of type Char (not VarChar).
Set the Format property to "fixed width" (Format tab).
Use the Display Width setting to specify the actual width of each column.

SET-FILE and SETFILE are different commands. The "TO" is not part of the command, it is displayed as a prompt requiring further input.

Execute the DS.TOOLS menu instead, and use the unlock facilities therein. This saves you fiddling with arcane demands that can do damage.

Try to expand your English language specification into step-by-step points, including any checking and verification that you might want to perform. This will probably make it clearer what activities you need in your job sequence.

This is a DataStage site, not an Oracle site. If the query works and generates what's needed, then as far as we're concerned it's correct.

If it used to work and doesn't now, what's changed?

You can not do the OR in a Lookup stage. You can do two separate lookups to the same source, and join the two result sets downstream.
This is more cleanly designed using two separate Lookup stages.

Welcome aboard. :D Does anyone else there know about SAP connectivity and how it's done at that particular site? There's more than one mechanism; which one you choose depends on what the SAP installation permits. It's really too long a topic to be dealt with here. Let's start with the stage types in...

Welcome aboard. :D

You manage this by including appropriate logic and exit commands in your script. For example exit 0 on success, exit 1 on failure. You can even return specific codes from shell variables, for example exit $reasoncode

That really depends on what is making those log entries, whether the job monitor or something else in the actual stage. The best I can offer as the answer is a definite maybe. Why not try one and let us know? As I understand things, DataStage still generates the row counts; job monitor collects them.

Is AMT nullable in the source DB2 table?

The job monitor collects those performance statistics you see in Designer (unless you switch their display off). You will also not be able to report row counts in the job log. If you use MetaStage the job monitor also has the responsibility of collecting the process metadata that will be sent into t...

I confess to being mystified. Can you please verify that the metadata (table definition) used in the job is totally correct? Even re-import it from the DCLGen to be sure.

Server jobs start up more quickly than parallel jobs, even parallel jobs on a single-node configuration. But I don't think this is your issue. How are you loading the rows into the target table? That is, what write rule are you following? If they are all new (insert) rows, prefer to use a bulk loader.

With a simple modification to your job design that populates the hashed file (not the one that uses it as a reference lookup) the task is even easier - an extra output link to a text files, with post-processing to remove duplicates (perhaps a sort -u command from an ExecSH after-stage subroutine).

This might sound silly, but I've seen it done. Check that the year/century is correct - for example that the job is not scheduled to run in 2106.

The easiest way is to set up counters in your job. You might use stage variables in a Transformer stage, you might use Aggregator stages with Count as the aggregation method.