DSXchange

Neither one is 'better', both are perfectly valid techniques. Some shops will have no truck with triggers and prefer to not use them, so find other mechanisms. One such is generating the surrogate inside the DataStage job stream, another is to use custom sql in the insert to leverage SeqName.nextval...

I don't believe so - Google around and see what you can find out.

If you switch to a secure method, sftp or scp, and setup RSA keys you can perform the transfer without 'needing' a password.

Isn't it just a matter of going into Services from the Control Panel, finding the service in question and clicking on 'Stop'?

There's no magic setting to help when you run more jobs than your system can handle. Suggest you do an Exact Search for your actual error message - "timed out while waiting for an event" - and start reading.

Exactly. So, why the 'need' to replicate this in DataStage when your database can do it for you? And if a database isn't involved - get it involved. Load your hierarchical data into a work table (or tables) and source from there.

The limit you set in your copy of the Director only applies to jobs started or scheduled from the Director client by you. Outside of the Director, your job control is responsible for setting the warning limits used for each run.

This is true in the 7.x version or only in 8.x?

True, the 'O/S level' step I mentioned could be leveraged in the Filter option of the Sequential File stage... say, something like 'tr' or 'awk'. My personal preference would be to do it as a separate step, for whatever that is worth.

This, I assume:

http://www.psoug.org/reference/connectby.html

How to replicate this Oracle functionality strictly in a DataStage job.

Ah... Poor Man's Load Balancing.

I don't know as I've never done it - only one or the other is all that is all that's needed. You should be able to run some tests to capture the exit status to determine which is in effect when both are used - does one trump the other? Is it order dependant? I have no clue. FWIW, we always use -jobs...

Reset the aborted job from the Director and let us know the contents of a log entry labelled 'From previous run...' - if one is logged, that is.

No, the issue seems to be the fact that you don't know what XPath Expressions are. They do all the dirty work in the stage and tell it how to parse the elements out that you want from the XML. They are generated for you automatically when you import the metadata from your source xml or better yet th...

Ken's website: http://www.kennethbland.com/

Typically that would involve some kind of O/S level preprocessing step to change those characters into a more 'traditional' delimiter the stage could then handle. Or read the record in as one long string and then use custom logic to parse the fields out inside the job.