DSXchange

Hi Guys

I have been reading thru the topics wrt jobs locking and noticed that Ray mentioned the Deadlock utility. Most of the topics covered the Unix environment.

In the Windows environment, would this simply be a case of editing the uvdlock.config file and changing it to start=1?

What I would also like to know is how much of a resource impact this has on a DataStage project. It seems as though it may be quite significant for Ascential to make the default setting start=0 i.e. don't start the utility

ewartpm wrote:In the Windows environment, would this simply be a case of editing the uvdlock.config file and changing it to start=1?

In any environment, actually, that is a perfectly acceptable way to enable it. Could also be 'dsdlock.config' depending on your version.

What I would also like to know is how much of a resource impact this has on a DataStage project.

I haven't noticed any difference to speak of with it on or off, but then I haven't specifically tried to hunt down or measure impact. Curious what others think. And, yes, it is interesting that in the recent past they changed the default to 'off'.

In my extremely limited experience the deadlock daemon consumed almost an entired CPU on our development system, so we had to turn it back off. My interval was set to 300. I am running HP-UX 11.11.

Tony

:D Thanks guys for the input.

WOW, got HPUX 11 weasing for air...

Seems it's wise to be careful with this one. I reckon I will switch it on and see what happens. I agree with Ray that this is the preferred way to go wrt managing the defunct processes, job locks etc. Maybe the trick is in setting the 'review' time. Sounds like in Tony's case 300 was a bit too soon.

By the way, how does DataStage do this at the moment if this option is not used? I ask this because I have a number of customers who are constantly complaining about the phantom/defunct processes that DataStage leaves running after a job is finished.

By the way, how does DataStage do this at the moment if this option is not used?

Without the deadlock daemon running DataStage does not clean up after defunct processes, as far as I am aware. There are some utilities that can be used to do so manually, such as dslictool. (This is functionally much the same as UniVerse's uvlictool - no surprise there - the difference being that the latter is documented in the UniVerse System Administration manual, which you can download from IBM's web site. I am unaware of any documentation for dslictool, except these fora.)

Interestingly enough, I turned it on briefly on our production system and watched for 1/2 hour or so and it wasn't bad at all. I think I had the interval set to 600 that time. Maybe the dev system was an anomaly?

Tony

I just watched it take 100% of a CPU here and then back back down. In checking the .config file, can anyone enlighten me on these two parameters?
I'm assuming 'timer' is how often it checks and that it is defined in seconds - is that correct? What is 'res'?

Never mind, I found it as part of the Help associated with the DEADLOCK.MENU command.

The 'interval timer' is defined in seconds and 'res' is 'resolution strategy'. The valid values are:

0 = Random
1 = Youngest
2 = Fewest Locks

Guess I'll stick with 'Random'.

It's all in Chapter 9 of Administering UniVerse manual, which can be downloaded from IBM web site.

My all-time favourite piece of UniVerse is the caption for option 6 of DEADLOCK.MENU: This is used for manual, rather than automatic resolution.

Deadlocks should not really occur in DataStage Repository, because all operations use the same code stream (the "helper subroutines"). Of course, that doesn't prevent you from generating a deadlock situation!