DSXchange

Nothing to prevent you layering some kind of business process management/governance over the top though.

I want to run the job for 10 different tables at the same time. Why? Aren't you concerned that you will overload (a) machine resources and (b) database licensed connections? To run genuinely simultaneously the job requests must be executed asynchronously, for example by using nohup backgrouound pro...

The operating system can show date/time accessed and date/time modified. Any save counts as a modification.

One of the services I perform is a DataStage health check. You would be surprised how many functions are unnecessarily multiply evaluated.

This is a case where I'd use stage variables to avoid unnecessary processing (in particular splitting the comma-delimited string more than once). For example: svFamilyName <-- Field(InLink.FullName, ",", 1, 1) svGivenNames <-- Field(InLink.FullName, ",", 2, 1) svFirstName <-- Fie...

(1) Somewhere in your data the byte sequence 0x8D is being found, which is not valid for ASCL_MS1252.

(2) Not really possible to tell. Disable operator combination and run the job again so that you can determine which actual stage is throwing the error.

It won't happen. The connector properties are too different from each other to warrant trying to be generic. (That's what ODBC is for.)

Although unrelated, you should run fsck fairly soon.

Check that the user is recorded in both the cron.allow and at.allow files.

I don't think so. You could estimate it by looking at the last modified date/time of the DSParams file in the project directory.

Get your Windows administrator to configure the user who executes DataStage jobs to be permitted to use the AT scheduler.

That suggests that you're sending the same key from separate nodes at the same time which, in turn, suggests that your partitioning algorithm is not properly specified (the key, the whole key and nothing but the key).

No. The configuration file is simply read when job execution is requested. No resolution of parameters or shell techniques is supported.

You could, of course, script something to rewrite the configuration file but, since it's only ever changed once per server, why would you bother?

What other Oracle processes are competing for access to the pertinent table(s), whether from DataStage or otherwise?

What is the default date format for parallel jobs? (Find out using the Administrator client.)

Have you overridden this default at project level or in the job itself?

Use a reject link on the reading Sequential File stage to determine what's actually being read.

That error will disappear when you resolve the job timeout error. The operator logic error simply informs you that it was a DataStage engine (Orchestrate) operator that detected the problem.