DSXchange

Are you using a single OCI stage with multiple links or multiple OCI stages, each with a single link? Try the first if you are doing the second, it helps keep the number of connections under control.

Otherwise, as noted, talk to your DBA about the limits they've imposed on you.

A couple of points from the original article on ADN:

1. This was for the 7.5x2 version.
2. On a Windows server.

Hence the confusion.

Ah... my first manuals still said VMARK on them, in spite of having purchased an Ascential product. What I didn't know was the 'UniData
merger' part. Oh, and I guess I was a little off on the product split version...

ray.wurlod wrote:Fewer.

Yes, yes, I know, not sure what I was thinking... 'fewer' for things that can be counted individually, and 'less' for those things that can't be. Mostly. I'd edit my original post but it would ruin the whole Feng Shui of it.

Welcome. Universe is the tree that DSEngine branched off from. From what I recall, Ascential removed unneeded Universe functionality, renamed it and continued developing it specifically into what we now know as 'DSEngine'. Somewhere in the 9.x version, I do believe. UniData is a different database, ...

Because, obviously, you never ran those two jobs at the same time before this! Good luck or bad, your pick.

Don't be sorry, how were you supposed to know? Ray doesn't usually quote because you get less points when you quote.

chucksmith wrote:At 7.5, make sure your DSN names do not contain spaces.

Yikes! Who does silly stuff like that?

But what about his second question? Did you reset (not recompile) the job and get any additional messages in the log labelled 'From previous run...'? More clues there if it shows up.

Use the Search, Luke! I quickly found 18 posts that mention this same error, including this one.

See if it helps you out.

Or a third option, depending on exactly what it is you plan on doing with these error files and what 'grain' they really need to be: 3) Rather than have each job worry about its own cat'ing, dump all of your error files into a common directory. Then you just need one job at the tail end of the proce...

Is PROD on another server or is it just another project on the same server as DEV and QA? If so, what's the difference between the two servers, anything obvious that could be causing this slowdown? When you say it "doesn't run on PROD" does that mean the first run always fails and the restart succee...

Very quick answers: No. Yes.

About the only person that thought all of it was free for the asking was Mr Smoely.

Heck, you can even download the MapStage plugin for DataStage from the eSupport site and it says very clearly in the readme that both TX and Design Studio are required to make any use of it.

As a user of that stage I see that behaviour as an entirely reasonable approach.