DSXchange

Use a Column Export stage.

Why not just use a common naming convention for the link that connects into the Oracle stage and create a simple routine that calls DSGetLinkInfo() function to return the link row count?

You claim to be a "data specialist at IBM". So what metrics do YOU think might indicate bottlenecks? Have you looked at the performance analyses? What are they showing you?

What is ORCHESTRATE.RuleSQLScript?

More specifically does your design include a column called RuleSQLScript and, if so, what is its value?

You can't have a single value that is a comma-delimited list (but still a string) and expect it to work with IN.

Read my earlier posts again. Your answer is there.

But you were asking earlier about performance, now you're asking about functional equivalence. What do you think?

kuldeep165146 wrote: i need to use Java, no other way.

I doubt that very much.

Message handlers are not supported for server jobs.

775 won't make it writable, unless you're in the root group. What you really need to have done originally is to have created a dstage group (or any other name) that is the (group) owner of all DataStage objects. All DataStage developers need to be in this group, and have a umask of 002.

No, because of the inserted tsort operator, which will unnecessarily re-sort your data.

My answer: it depends. If there is no operator combination, you can estimate that there is one process per node for each stage (operator) in the job. Sometimes you will get composite operators, which require more than one process. In terms of data transfer, less is better. Transfer the smallest poss...

Part of the restartability design might well involve capturing a snapshot that you can use when restarting.

Short answer: no. An ORDER BY may be faster than a DataStage sort, if the sort columns are indexed. A B-tree index is already stored in sorted order. However, the Join stage will insert a tsort operator unless you precede it immediately with a Sort stage specifying "Don't sort (previously sorte...

Jaydev

Awaiting your reply.

Thanks

It has been discussed a number of times in the past. Basically you have to design the 3rd job so that it can pick up where it left off - there is no automatic mechanism for achieving this. The design, clearly, involves some kind of persistent "remembering" which rows have been processed su...

You can bring the environment variable into the job as a parameter and change its default value to the special token $UNSET.