DSXchange

Detect the failure in your job sequence and use a Routine activity to invoke UtilityFatalToLog() or UtilityWarningToLog().

Not legally.

Parameter values are set when the job run request is made.

Welcome aboard. Please maintain a professional standard of written English here on DSXchange. This will help those whose first language is not English.

Can you be more explicit? I understand that you want to set environment variables from a DataStage job. If that's correct, simply execute an appropriate command or pipeline of commands. For example set MYVAR=#valuetoset# You could execute this command (for example, still) via ExecDOS as an after-job...

You don't need a routine. You can use a DataStage job. Pick up the value and stick it in a file or (better) in that job's user status area. (OK, you will need a two-line routine for that, but the code exists on DSXchange.) Pick up the value of the user status area when assigning the value to the job...

Get yourself a premium membership so that you can read the entirety of my posts. I made this quite clear.

Sounds like you're in need of a more professional support organization!

Nagaraj wrote:Thanks for the information.
Could you please tell me when we can use those stages (wisd input and wisd output)?

When you're planning to expose the job as a web service.

There are no nuances.

A Lookup stage still performs a join - by default a left outer join, but this can be an inner join if the Lookup Failed rule is set to "Drop". Had I meant a Join stage the word would have had a capital "J". In that context please re-read my earlier post, particularly about using a key-based partitio...

Is the database set up with no logging? I've seen that cause "transaction not available" in the past.

Possibly the same key arriving to Oracle from more than one partition?

In earlier versions of DataStage these stage types were called the RTI ("real time interface") input and output stages; you may still encounter that terminology. Simplistically: Regular job source_stage ---> processing_stages ---> target_stage Job to be deployed as web service WISD_input_stage ---> ...

... only if you know that the final comma is always there. Otherwise the command becomes a tad more complex. Still do-able, but caution is advised.

The status of each job is recorded in a separate table.

Therefore, at the innermost level, you need a separate query for each job.

Wrap that how you will, the bottom line is one query per job.