DSXchange

And now the post in the Server forum has a job type of PX.

Short answer: as one long varchar field. Long answer would depend on exactly what you needed from it.

Bummer... was looking for something simple that would explain the delay at the end of processing. What about the first question - is this behaviour repeatable? I wonder if the delay is space management / allocation going on in the database...

This is repeatable or it only happened once? What stage are you using for the target? What update action? Are you doing anything 'after SQL' in the stage?

I agree - it *should* be.

I was wondering about a difference in volume in the link that goes to the Aggregator, dev versus test. 'Large' volumes can make it fall over dead. However, it sounds like everything would be identical there. So, are you saying that your dev and test DataStage servers are separate server? If so, what...

Then you need to track down what's different between dev and test. Are they two different DataStage environments or are both projects on the same server? What about the data itself? Same source? Is there a significant delta in the volumes? If not, first check could be to copy the job, pop off the Ag...

Well, ok then.

Didn't tell you to Reset it and then rerun it. Reset it. Stop. Take a deep breath. Then check the log.

No, not really. How about explaining what your job does, how it is designed? Let's start there. IDENT1 would be a transformer that it added between two passive stages, btw.

Tuning is tuning and has nothing to do with DataStage directly. What the heck is QTODBC? Just some kind of query tool, it seems. If you need help using that, you should check to see if they have a dedicated support forum.

Have you opened a support case?

.5? Come on, someone had to say it.

Quite a lot, actually, including a major architectural change. I'm sure there are resources out there, either on IBM's official site or even in Vincent's blog that discuss that.

chulett wrote:Reset the aborted job and let us know the contents of any 'From previous run...' log message.

Did you do this? Did any such message get added to the log?

With so little information? No.

Reset the aborted job and let us know the contents of any 'From previous run...' log message.