DSXchange

Details, please. I could guess but I'd really rather not. What database and what is your target field type? What exactly are you doing now and what errors are you seeing?

That is also in the linked topic, there is an orchadmin command to delete datasets from the command line.

No. there's no configuration option for that. That's completely under the control of the O/S rather than DataStage. Well... other than strict scheduling and specific job designs, I suppose.

Exactly. How would you do it if you took DataStage out of the picture? That's the same way you would have DataStage do it.

That's great and all, though I don't really agree with your conclusion. Never mind the fact that the post is about how to establish dependancies between already established projects, not one seeking advice on how to set up new projects.

Any "unusual" data types you are using? A LONG or CLOB for example? If not, please give us a better idea of what you're doing in the Oracle stage and the nature of the data you are "loading".

Please try to do a better job of identifying what the 'bottleneck' jobs have in common to see where exactly they might be 'hanging up'. Are they all doing database work? If so, what kind? Again if so, check your 'explain plans' (or equivalent) to make sure they haven't changed in any significant fas...

Thanks for posting your resolution. I would have posted something but it wouldn't have been all that helpful, never having played with VM on a laptop and then carting it around like you've been doing.

I take it we're not talking about the Mainframe / 390 version of DataStage here, yes?

Actually, it creates a folder with three files in it.

I don't think there's really an elegant way. Typically, one would use All rather than Any sequencers but as you noted, the longest running job in each segment will be the bottleneck. But on the flip-side, as you have it now the shortest job will trigger the next segment so hopefully the segments are...

'All' means all input links directly connected to the stage, regardless of what may or may not have happened with any upstream activities and their associated links / triggers. So your last stage only cares about the state of jobs 7, 8 and 9.

I prefer using the '-DEV/TEST/UAT/PROD' part of the name as a suffix, because I prefer projects to sort by name rather than environment when mixed on the same server. Still just a personal preference in the end, so you could end up with something like this: A-DEV A-TEST A-UAT B-DEV B-TEST B-UAT -or-...

Technically, it hasn't been "Universe" for years now.

Ah... thanks for that clarification.