DEADLOCK.MENU
Moderators: chulett, rschirm, roy
DEADLOCK.MENU
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
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
Re: DEADLOCK.MENU
In any environment, actually, that is a perfectly acceptable way to enable it. Could also be 'dsdlock.config' depending on your version.ewartpm wrote:In the Windows environment, would this simply be a case of editing the uvdlock.config file and changing it to start=1?
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'.What I would also like to know is how much of a resource impact this has on a DataStage project.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
- Premium Member
- Posts: 483
- Joined: Thu Jun 12, 2003 4:47 pm
- Location: St. Louis, Missouri USA
: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.
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.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
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.)By the way, how does DataStage do this at the moment if this option is not used?
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Premium Member
- Posts: 483
- Joined: Thu Jun 12, 2003 4:47 pm
- Location: St. Louis, Missouri USA
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'?
Code: Select all
timer=60
res=0
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
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'.
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'.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
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!
Code: Select all
Select victim for deadlock 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!
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.