Deadlock Detection Interval

[ca.portal.admin]

Has anybody done any benchmarks on how much CPU the Deadlock Detection
mechanism uses?

I have the interval set to 1 and so deadlocks are detected pretty much
immediately. But am I spending lots of CPU unneccessarily? I mean if someone
is going to deadlock and get rolled out does it really matter if it happens
in the next 0.5 seconds or 5 seconds on average.

We think we have a lot of deadlocks but actually compared to the number of
transactions it is really small - perhaps 1 an hour. So in 1 hour with DDI =
1 the CV checks 3600 times and only detects a problem once.

I'm sure there is some overhead, but does anyone know how much? Is it worth
playing with it?

I am R15.0 SP7 Z/OS.


An aside: I met a Lesbian DBA at a party at the weekend. Naturally I was
horrified and disgusted and decided she needed converting. But after 3 hours
of my preaching and me buying 4 Southern Comforts and lemonade for her, she
still believed that DB2 was better. Does anyone know how to recognise a
relational model DBA from a distance? Can I claim the cost of the drinks
from the IUA?

______________________________________________________________

Chris Trayler, IXD
Bank Julius Baer & Co. Ltd.
P. O. Box, CH-8010 Zürich, Switzerland
Telephone [phone], Fax [phone]
www.juliusbaer.com <http://www.juliusbaer.com/>

______________________________________________________________

*****JuliusBaer Disclaimer***** This message is for the addressee only and
may contain confidential or privileged information. You must delete and not
use it if you are not the intended recipient. It may not be secure or
error-free. All e-mail communications to and from the Julius Baer Group may
be monitored. Processing of incoming e-mails cannot be guaranteed. Any views
expressed in this message are those of the individual sender. This message
is for information purposes only. All liability of the Julius Baer Group and
its entities for any damages resulting from e-mail use is excluded. US
persons are kindly requested to read the important legal information
presented at following URL: http://www.juliusbaer.com/maildisclaimer


"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
Deadlock Detection Interval
"Has anybody done any benchmarks on how much CPU the Deadlock Detection mechanism uses?

I have the interval set to 1 and so deadlocks are detected pretty much immediately. But am I spending lots of CPU unneccessarily? I mean if someone is going to deadlock and get rolled out does it really matter if it happens in the next 0.5 seconds or 5 seconds on average.

We think we have a lot of deadlocks but actually compared to the number of transactions it is really small - perhaps 1 an hour. So in 1 hour with DDI = 1 the CV checks 3600 times and only detects a problem once.

I'm sure there is some overhead, but does anyone know how much? Is it worth playing with it?

I am R15.0 SP7 Z/OS.


An aside: I met a Lesbian DBA at a party at the weekend. Naturally I was horrified and disgusted and decided she needed converting. But after 3 hours of my preaching and me buying 4 Southern Comforts and lemonade for her, she still believed that DB2 was better. Does anyone know how to recognise a relational model DBA from a distance? Can I claim the cost of the drinks from the IUA?

______________________________________________________________

Chris Trayler, IXD
Bank Julius Baer & Co. Ltd.
P. O. Box, CH-8010 Zürich, Switzerland
Telephone [phone], Fax [phone]
www.juliusbaer.com <http://www.juliusbaer.com/>

______________________________________________________________

*****JuliusBaer Disclaimer***** This message is for the addressee only and may contain confidential or privileged information. You must delete and not use it if you are not the intended recipient. It may not be secure or error-free. All e-mail communications to and from the Julius Baer Group may be monitored. Processing of incoming e-mails cannot be guaranteed. Any views expressed in this message are those of the individual sender. This message is for information purposes only. All liability of the Julius Baer Group and its entities for any damages resulting from e-mail use is excluded. US persons are kindly requested to read the important legal information presented at following URL: http://www.juliusbaer.com/maildisclaimer
"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
Re: batch ACCEPT SYSVERSION
"While we know that ACCEPT SYSVERSION is an IDMS-DC construct that only
works when actually running inside the IDMS region - it is useful to
know which CV a batch program is running against. If running in local
mode you would need something in the database - as previously suggested.


What we do in CV mode is call a program that accesses the dataset name
of the SYSCTL file - and based on its name it returns a ""sysversion"" -
derived based on known naming standards. This has worked well for us -
could probably share the code if that would help.

HTH - cheers - Gary

Gary Cherlet
Justice Technology Services
Department of Justice, SA Government
Telephone [phone]
Facsimile [phone]
Mobile [phone]
MailTo:[e-mail]

This e-mail message and any attachments are qualified as follows:
Addressing: If you have received this e-mail in error, please advise by
reply e-mail to the sender. Please also destroy the original
transmission and its contents. Confidentiality: This e-mail may contain
confidential information which also may be legally privileged. Only the
intended recipient(s) may access, use, distribute or copy this e-mail.
Individual Views: Unless otherwise indicated, the views expressed are
those of the sender, not Justice Technology Services. Computer Viruses:
It is the recipient's responsibility to check the e-mail and any
attached files for viruses.

[ca.portal.admin]

Hi Lutz,
You're more or less on the right track.
Running a batch job with the interval at 2 different values AND running
some
sort of monitor for CPU usage, will give one an idea of how much
overhead
the deadlock detection process will use. However, you have to have the
same
task load in both tests in order to make the numbers relate. This is
because
the deadlock detector has to look around and collect information about
all
tasks that are waiting at the time it wakes up. If, on one interval
there
are 3 tasks and on another interval there are 17 tasks, the CPU used
will be
different. How much different, I can't even begin to guestimate.
As to task type, it is a DC task. This is why it can only gain control
when
the currently active task waits. (Have to watch out for runaway tasks.)
The deadlock detection processed was removed from dispatcher with the
development of R12. The deadlock detection interval simply controls how
often the deadlock detector wakes up and looks around for a deadlock.
For
sites that have a large task load there is even an ability to change the
scale of the deadlock interval into 100ths (I believe it is 100ths) of a
second. By using this option, a deadlock detection interval of 100 would
be
the same as a deadlock detection interval of 1, with the option turned
off.
Chuck

[ca.portal.admin]

Chris, it is over .05%. I can't say exactly, because I dont remember
the number reliably, but it is substantial enough to warrant a try. I
understand your political situation of introducing it in production, and
having to make promises first. But realistically, you can test it in
development very well, by running a batch update job through cv. Lots
of IDMS calls gives you lots of traffic through the wait/dispatch
mechanism that does deadlock detection. If you reliably see a
difference in IDMS CPU consumption for the same load, then you can
extrapolate it, and justify it to production control.

Lutz Petzold




This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna
"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
Re: Deadlock Detection Interval
"Es kann manchmal schwierig sein.

[ca.portal.admin]

Chuck, changing the deadlock detection interval AND running a batch
job should show you the difference in CPU consumption. You say task, is
that an IDMS task or and MVS attached task running under its own TCB?
In either case, something like Omegamon reports on all TCB's for an
address space, and the CPU difference should show up there.
I did not know that with r12 the deadlock detection code was taken out
of the wait/dispatch routine. If that is true, then it seems that the
IDMS code has been reworked to take advantage of less frequent checking
and the deadlock detection parm may be absolete, or may not serve the
same purpose as it once did.



Lutz Petzold
This e-mail may contain confidential or privileged information. If you
think you have received this e-mail in error, please advise the sender
by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna

*****JuliusBaer Disclaimer***** This message is for the addressee only and may contain confidential or privileged information. You must delete and not use it if you are not the intended recipient. It may not be secure or error-free. All e-mail communications to and from the Julius Baer Group may be monitored. Processing of incoming e-mails cannot be guaranteed. Any views expressed in this message are those of the individual sender. This message is for information purposes only. All liability of the Julius Baer Group and its entities for any damages resulting from e-mail use is excluded. US persons are kindly requested to read the important legal information presented at following URL: http://www.juliusbaer.com/maildisclaimer
"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
Re: Deadlock Detection Interval
"Thanks Pete. That was what I wanted to know. 75 CPU seconds per 24 hour
period is clearly Erdnusse (Peanuts in English).

My production Cvs right now.

SDSF DA PRDA PRDA PAG 0 CPU/L 88/ 86 LINE 1-3 (3)

COMMAND INPUT ===> SCROLL
===> CSR
PREFIX=PIDMS* DEST=(ALL) OWNER=* SORT=JOBNAME/A SYSNAME=

NP JOBNAME StepName ProcStep JobID Owner C Pos DP Real Paging
SIO CPU% ASID ASIDX EXCP-Cnt CPU-Time SR Status SysN
PIDMS1 IDMS#001 IDMSEXEC JOB09059 PIDMS1 M NS EE 733T 0.00
420.23 21.57 94 005E 12M 19423.33 PRDA
PIDMS2 IDMS#002 IDMSEXEC JOB09223 PIDMS2 M NS E4 26T 0.00
0.00 0.01 97 0061 9,049 10.91 PRDA
PIDMS3 IDMS#003 IDMSEXEC JOB09065 PIDMS3 M NS EE 34T 0.00
34.66 0.27 95 005F 282,745 122.74 PRDA

75 seconds taken off around 20,000 is still around 20,000.


I haven't got PMDC so I will take your word for it. I don't think it is
worth disturbing the status quo for this one.

The German was for Lutz's benefit. He implied that my German was
probably rubbish. That may well be true but I did a 4 hour presentation
this morning all in German and it appeared that my audience understood
the language if not the concepts behind the talk.

[ca.portal.admin]

Chuck, changing the deadlock detection interval AND running a batch
job should show you the difference in CPU consumption. You say task, is
that an IDMS task or and MVS attached task running under its own TCB?
In either case, something like Omegamon reports on all TCB's for an
address space, and the CPU difference should show up there.
I did not know that with r12 the deadlock detection code was taken out
of the wait/dispatch routine. If that is true, then it seems that the
IDMS code has been reworked to take advantage of less frequent checking
and the deadlock detection parm may be absolete, or may not serve the
same purpose as it once did.



Lutz Petzold
This e-mail may contain confidential or privileged information. If you
think you have received this e-mail in error, please advise the sender
by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna

*****JuliusBaer Disclaimer***** This message is for the addressee only
and may contain confidential or privileged information. You must delete
and not use it if you are not the intended recipient. It may not be
secure or error-free. All e-mail communications to and from the Julius
Baer Group may be monitored. Processing of incoming e-mails cannot be
guaranteed. Any views expressed in this message are those of the
individual sender. This message is for information purposes only. All
liability of the Julius Baer Group and its entities for any damages
resulting from e-mail use is excluded. US persons are kindly requested
to read the important legal information presented at following URL:
http://www.juliusbaer.com/maildisclaimer
"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
Re: Deadlock Detection Interval
"DEAD basically does all it's own work with few calls to any other system
service, UNTIL, a deadlock is found. When a deadlock is found, it writes out
the DC001000, optionally the DC001001, and the DC001002 messages. Those
messages are handled just as any other message would be, a #WTL is used. The
only ""difference"" is that WTL is told not to go to the dictionary, ""here's
the text"" in the call. If multitasking is on, then there will be some
overhead to the internal lock manager (not to be confused with LMGR) to
single thread access to certain chains that could be updated on another TCB.
In that situation, there is a corresponding call to unlock the chain. An
example of a chain would be the dispatch chain.
If you code a deadlock victim selection exit, then it will be called via
RHDCUXIT to get there.
That's about it for the most part.

[ca.portal.admin]

Chuck, changing the deadlock detection interval AND running a batch
job should show you the difference in CPU consumption. You say task, is
that an IDMS task or and MVS attached task running under its own TCB?
In either case, something like Omegamon reports on all TCB's for an
address space, and the CPU difference should show up there.
I did not know that with r12 the deadlock detection code was taken out
of the wait/dispatch routine. If that is true, then it seems that the
IDMS code has been reworked to take advantage of less frequent checking
and the deadlock detection parm may be absolete, or may not serve the
same purpose as it once did.



Lutz Petzold
This e-mail may contain confidential or privileged information. If you
think you have received this e-mail in error, please advise the sender
by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna

*****JuliusBaer Disclaimer***** This message is for the addressee only and may contain confidential or privileged information. You must delete and not use it if you are not the intended recipient. It may not be secure or error-free. All e-mail communications to and from the Julius Baer Group may be monitored. Processing of incoming e-mails cannot be guaranteed. Any views expressed in this message are those of the individual sender. This message is for information purposes only. All liability of the Julius Baer Group and its entities for any damages resulting from e-mail use is excluded. US persons are kindly requested to read the important legal information presented at following URL: http://www.juliusbaer.com/maildisclaimer
"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
Re: Deadlock Detection Interval
"Wow, I can't win for losing. Chris, I didn't intend to imply that your
German was rubbish, unless you're implying my English is rubbish.
Hmmm....on second thought...............


Lutz Petzold

This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna
"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
Re: Deadlock Detection Interval
"We use sub-second deadlock detection, with no noticeable degradation in
response time, nor no measurable increase in task cpu time (that time
may not be captured per task in SMF).

It depends more on the number of Deadlocks you get per day, rather than
the number of tasks: I mean the overhead of deadlock detection, even at
sub-second intervals is bearable, unlike the task congestion that
results when deadlocked tasks hold onto resources.

If you are running 60 TPS with 30 concurrent tasks (to pick a numbers
arbitrarily, tho' not whimsically, if you see what I mean), and you
encounter a deadlock, you will quickly see the TPS drop and the
concurrent tasks rise, albeit for the short duration of the deadlock
detection interval, plus rollout time.

So we choose to minimize that interval . . .

Thanks to you all for a most interesting and educational tutorial this
morning...

dem

[ca.portal.admin]

Chuck, changing the deadlock detection interval AND running a batch
job should show you the difference in CPU consumption. You say task, is
that an IDMS task or and MVS attached task running under its own TCB?
In either case, something like Omegamon reports on all TCB's for an
address space, and the CPU difference should show up there.
I did not know that with r12 the deadlock detection code was taken out
of the wait/dispatch routine. If that is true, then it seems that the
IDMS code has been reworked to take advantage of less frequent checking
and the deadlock detection parm may be absolete, or may not serve the
same purpose as it once did.



Lutz Petzold
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna
"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
Re: Deadlock Detection Interval
"Thanks.

At 10:36 AM 10/4/2007, you wrote:

Hi Chris,

Do not understand the foreign language bit.
Do you have PMDC?

If so try option 3.1 and you see RHDCDEAD and it reports CPU time.

Looking at two of our busy systems one shows 75 seconds this one has
been up for 11 days and DCMT D STA SYS reports that it has used 3 hours
and 20 minutes CPU.

We have a task that resets the system and user CPU time to zero and this
runs every night
So DCMT D STA SYS is reporting CPU used today.

The other shows 146 seconds this one has been 26 days and so far DCMT D
STA SYS shows 4 hours and 44 minutes CPU.

Now assuming that PMDC has got its numbers correct it seems that
RDHCDEAD is not a large or even a significant overhead.

Sorry should have said we have the Deadlock Detection Interval set to 1.

Pete

[ca.portal.admin]

Chuck, changing the deadlock detection interval AND running a batch
job should show you the difference in CPU consumption. You say task, is
that an IDMS task or and MVS attached task running under its own TCB?
In either case, something like Omegamon reports on all TCB's for an
address space, and the CPU difference should show up there.
I did not know that with r12 the deadlock detection code was taken out
of the wait/dispatch routine. If that is true, then it seems that the
IDMS code has been reworked to take advantage of less frequent checking
and the deadlock detection parm may be absolete, or may not serve the
same purpose as it once did.



Lutz Petzold
This e-mail may contain confidential or privileged information. If you
think you have received this e-mail in error, please advise the sender
by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna

*****JuliusBaer Disclaimer***** This message is for the addressee only and
may contain confidential or privileged information. You must delete and not
use it if you are not the intended recipient. It may not be secure or
error-free. All e-mail communications to and from the Julius Baer Group may
be monitored. Processing of incoming e-mails cannot be guaranteed. Any views
expressed in this message are those of the individual sender. This message
is for information purposes only. All liability of the Julius Baer Group and
its entities for any damages resulting from e-mail use is excluded. US
persons are kindly requested to read the important legal information
presented at following URL: http://www.juliusbaer.com/maildisclaimer
"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
Re: Deadlock Detection Interval
"A question for Chuck - probably - Pete had the strobe figure for
RHDCDEAD . Is it just RHDCDEAD that spends CPU during a DD cycle or does
it call all sorts of other modules? His 75 seconds could be just one
part of a larger amount - or not.

I'm sure somebody out there has actually measured it at some time.

[ca.portal.admin]

Chuck, changing the deadlock detection interval AND running a batch
job should show you the difference in CPU consumption. You say task, is
that an IDMS task or and MVS attached task running under its own TCB?
In either case, something like Omegamon reports on all TCB's for an
address space, and the CPU difference should show up there.
I did not know that with r12 the deadlock detection code was taken out
of the wait/dispatch routine. If that is true, then it seems that the
IDMS code has been reworked to take advantage of less frequent checking
and the deadlock detection parm may be absolete, or may not serve the
same purpose as it once did.



Lutz Petzold
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna
"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
Re: Deadlock Detection Interval
"Hey Pete

I seem to remember that BT had that optional fix for 100ths of a second.
If it has then your DDI of 1 using 75 seconds CPU is even more
impressive because it would be waking up 100 times a second.

Chris

[ca.portal.admin]

A question for Chuck - probably - Pete had the strobe figure for
RHDCDEAD . Is it just RHDCDEAD that spends CPU during a DD cycle or does
it call all sorts of other modules? His 75 seconds could be just one
part of a larger amount - or not.

I'm sure somebody out there has actually measured it at some time.

[ca.portal.admin]

The deadlock detection interval was not always a feature of IDMS.
Somewhere in its post 10.0 life, someone at Cullinet had done some
studies and determined that IDMS spends some major time executing the
deadlock detection code and walking lock chains. This deadlock detection
interval was then developed. My personal opinion is, they didn't
develop things lightly, and there must have been some major push for it,
possibly from a customer, like BT. Although I am wildly guessing here.
I do know that at one time it was thought to be a great idea. As far as
delaying the termination of a task that's deadlocked anyway by some
seconds, I dont think it's a major deal. You will save CPU cycles
though. How much, I've heard, but the percentage was so large that I
would not say it out loud. Try it and see. If all of your tasks,
except the exception, finish in under a minute, I would try it,
benchmark it before and after. Benchmark the tasks, if you can, instead
of just all of IDMS. Unfortunately you'll have to turn task statistics
on, which will increase your overhead and CPU consumption, so be weary.
Maybe just a measure for all of IDMS on like days, before and after to
see if there's promise, to start with.

Lutz Petzold

This e-mail may contain confidential or privileged information. If you
think you have received this e-mail in error, please advise the sender
by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna

*****JuliusBaer Disclaimer***** This message is for the addressee only and may contain confidential or privileged information. You must delete and not use it if you are not the intended recipient. It may not be secure or error-free. All e-mail communications to and from the Julius Baer Group may be monitored. Processing of incoming e-mails cannot be guaranteed. Any views expressed in this message are those of the individual sender. This message is for information purposes only. All liability of the Julius Baer Group and its entities for any damages resulting from e-mail use is excluded. US persons are kindly requested to read the important legal information presented at following URL: http://www.juliusbaer.com/maildisclaimer
"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
Re: Deadlock Detection Interval
"The deadlock detection interval was not always a feature of IDMS.
Somewhere in its post 10.0 life, someone at Cullinet had done some
studies and determined that IDMS spends some major time executing the
deadlock detection code and walking lock chains. This deadlock detection
interval was then developed. My personal opinion is, they didn't
develop things lightly, and there must have been some major push for it,
possibly from a customer, like BT. Although I am wildly guessing here.
I do know that at one time it was thought to be a great idea. As far as
delaying the termination of a task that's deadlocked anyway by some
seconds, I dont think it's a major deal. You will save CPU cycles
though. How much, I've heard, but the percentage was so large that I
would not say it out loud. Try it and see. If all of your tasks,
except the exception, finish in under a minute, I would try it,
benchmark it before and after. Benchmark the tasks, if you can, instead
of just all of IDMS. Unfortunately you'll have to turn task statistics
on, which will increase your overhead and CPU consumption, so be weary.
Maybe just a measure for all of IDMS on like days, before and after to
see if there's promise, to start with.

Lutz Petzold

This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna
"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
Re: Deadlock Detection Interval
"Chris,
I can't address the benchmark aspect of deadlock detection overhead, I
simply don't have that kind of information available, but I would like to
point out that when a deadlock occurs, and it hasn't been detected, all the
locks held by the task that will eventually go away, could be keeping others
from completing there assigned mission. So, if you change the deadlock
interval from 1, to say 5, seconds, then for the 5 seconds that the deadlock
task remains in the system, all locks held by that task can keep other tasks
from completing. Now, since we are referring to a deadlocked task, we know
that the other tasks that are waiting on the deadlocked task are not
involved in the deadlock, allowing them to finish won't clear up the
deadlock, so why hold them up if they can complete. Furthermore, while these
tasks are waiting on locks held by the deadlocked task, they, too, could be
holding locks which cause other tasks to wait.
Does this all make sense?
So, the bottom line is, yes, you can increase the deadlock detection
interval. Yes, you are averaging only one deadlock every hour. But, what
impact would there be if you did increase the interval?
As long as you go into this type of a change knowing what could happen, then
you can make an educated decision as to whether or not to leave the interval
longer or go back to a shorter interval.
Also keep in mind that task resources are involved here as well. Single
threaded programs, storage, ENQUEUEs, etc, are all held until the deadlocked
task is aborted. They, too, can be a bottleneck as long as the deadlocked
task remains in the system.
Hope this helps.
Chuck

[ca.portal.admin]

Es kann manchmal schwierig sein.

[ca.portal.admin]

Es kann manchmal schwierig sein.

[ca.portal.admin]

Deliberate mistake? Sometimes I am wise beyond intention. But suffice
it to say, my English is probably like your German.



This e-mail may contain confidential or privileged information. If you
think you have received this e-mail in error, please advise the sender
by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna

*****JuliusBaer Disclaimer***** This message is for the addressee only
and may contain confidential or privileged information. You must delete
and not use it if you are not the intended recipient. It may not be
secure or error-free. All e-mail communications to and from the Julius
Baer Group may be monitored. Processing of incoming e-mails cannot be
guaranteed. Any views expressed in this message are those of the
individual sender. This message is for information purposes only. All
liability of the Julius Baer Group and its entities for any damages
resulting from e-mail use is excluded. US persons are kindly requested
to read the important legal information presented at following URL:
http://www.juliusbaer.com/maildisclaimer
"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
Re: Deadlock Detection Interval
"Chuck, changing the deadlock detection interval AND running a batch
job should show you the difference in CPU consumption. You say task, is
that an IDMS task or and MVS attached task running under its own TCB?
In either case, something like Omegamon reports on all TCB's for an
address space, and the CPU difference should show up there.
I did not know that with r12 the deadlock detection code was taken out
of the wait/dispatch routine. If that is true, then it seems that the
IDMS code has been reworked to take advantage of less frequent checking
and the deadlock detection parm may be absolete, or may not serve the
same purpose as it once did.



Lutz Petzold
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna
"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
Re: Deadlock Detection Interval
"Hi Lutz,

I'm not sure that what you're suggesting will tell Chris what he needs to
know. As you pointed out, Pre-R12, deadlock detection was performed as part
of the WAIT/DISPATCH process. If memory serves me correctly, as a task was
about to wait, the dispatcher checked all other waiters to see if a deadlock
condition would occure, and, if so, deny the wait, abort the task, etc...

In R12 and later, the deadlock detection was moved out of the dispatcher and
made a separate task, service driver for lack of a better analogy.

As a separate task, the deadlock detector wakes up at some specified
interval, collects information about all the waiters in the CV, analyzes the
information it collected and, of a deadlock exists, determines a victim,
calls the victim selection exit if one exists and then cancels the selected
victim. Once the victim has been selected, it removes the information about
the victim from its collection of information and performs the analysis
again to see if there is still a deadlock. If so, it repeats the process of
selecting and cancelling again. This process continues until no deadlock
condition exists with the current collection of information. At this point,
the deadlock detector goes back to sleep for the specified interval.

So, running a batch job doing a lot of updates will not change the frequency
or load that the deadlock detection process places on the system. The load
that the deadlock detection process has on the system is a function of the
load on the system. The more active tasks there are, the more information to
analyze. That is where the load of the deadlock detector comes from.

The bigger issue, I believe, is how long a deadlocked task is allowed to
hold resources from other tasks before it is recognized and abended. That is
the deadlock detection interval's job.

I don't know if this helps or hurts Chris' ablilty to load test the deadlock
detection process, but I hope it helps to at least understand what is going
on with deadlock detection.

Chuck

[ca.portal.admin]

Deliberate mistake? Sometimes I am wise beyond intention. But suffice
it to say, my English is probably like your German.



This e-mail may contain confidential or privileged information. If you
think you have received this e-mail in error, please advise the sender
by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna

*****JuliusBaer Disclaimer***** This message is for the addressee only and may contain confidential or privileged information. You must delete and not use it if you are not the intended recipient. It may not be secure or error-free. All e-mail communications to and from the Julius Baer Group may be monitored. Processing of incoming e-mails cannot be guaranteed. Any views expressed in this message are those of the individual sender. This message is for information purposes only. All liability of the Julius Baer Group and its entities for any damages resulting from e-mail use is excluded. US persons are kindly requested to read the important legal information presented at following URL: http://www.juliusbaer.com/maildisclaimer
"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
Re: Deadlock Detection Interval
"Deliberate mistake? Sometimes I am wise beyond intention. But suffice
it to say, my English is probably like your German.



This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna
"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
Re: Deadlock Detection Interval
"Chris, it is over .05%. I can't say exactly, because I dont remember
the number reliably, but it is substantial enough to warrant a try. I
understand your political situation of introducing it in production, and
having to make promises first. But realistically, you can test it in
development very well, by running a batch update job through cv. Lots
of IDMS calls gives you lots of traffic through the wait/dispatch
mechanism that does deadlock detection. If you reliably see a
difference in IDMS CPU consumption for the same load, then you can
extrapolate it, and justify it to production control.

Lutz Petzold




This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna
"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
Re: Deadlock Detection Interval
"Hey Lutz - can you whisper the percentage? Or write it down?

My problem is the usual one. We don't get any deadlocks in test because
there isn't enough activity. If I just vary it in Production and it
works then I am a hero. If I vary it in production and tasks start
bombing out then I am an evil, vindictive, incompetent who tinkers with
the production system just to annoy people and wreck the business.

I might take the risk if I had some idea of the possible gain but if I
risk it all for a potential 0.5% then I am going to look like a wally.
(Does that translate into American English?)

This has come about because of my brilliant redesign of buffers and
dataspaces in the system which has made everything go really fast. But
every I/O I save translates into a bit more CPU. Obviously the upstairs
gods like the fast response bit but they don't like the lots of CPU bit.

Ideally they would like instant response with no I/O and No CPU and the
whole thing to run as a background task on a second hand mobile phone.

I like your deliberate mistake in your answer. I assume you mean wary
and not weary. I'm putting the weary bit down to my age and lifestyle.

[ca.portal.admin]

Deliberate mistake? Sometimes I am wise beyond intention. But suffice
it to say, my English is probably like your German.



This e-mail may contain confidential or privileged information. If you
think you have received this e-mail in error, please advise the sender
by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna

*****JuliusBaer Disclaimer***** This message is for the addressee only
and may contain confidential or privileged information. You must delete
and not use it if you are not the intended recipient. It may not be
secure or error-free. All e-mail communications to and from the Julius
Baer Group may be monitored. Processing of incoming e-mails cannot be
guaranteed. Any views expressed in this message are those of the
individual sender. This message is for information purposes only. All
liability of the Julius Baer Group and its entities for any damages
resulting from e-mail use is excluded. US persons are kindly requested
to read the important legal information presented at following URL:
http://www.juliusbaer.com/maildisclaimer
"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
Re: Deadlock Detection Interval
"Hi Lutz,
You're more or less on the right track.
Running a batch job with the interval at 2 different values AND running some
sort of monitor for CPU usage, will give one an idea of how much overhead
the deadlock detection process will use. However, you have to have the same
task load in both tests in order to make the numbers relate. This is because
the deadlock detector has to look around and collect information about all
tasks that are waiting at the time it wakes up. If, on one interval there
are 3 tasks and on another interval there are 17 tasks, the CPU used will be
different. How much different, I can't even begin to guestimate.
As to task type, it is a DC task. This is why it can only gain control when
the currently active task waits. (Have to watch out for runaway tasks.)
The deadlock detection processed was removed from dispatcher with the
development of R12. The deadlock detection interval simply controls how
often the deadlock detector wakes up and looks around for a deadlock. For
sites that have a large task load there is even an ability to change the
scale of the deadlock interval into 100ths (I believe it is 100ths) of a
second. By using this option, a deadlock detection interval of 100 would be
the same as a deadlock detection interval of 1, with the option turned off.
Chuck

[ca.portal.admin]

Hey Pete

I seem to remember that BT had that optional fix for 100ths of a second.
If it has then your DDI of 1 using 75 seconds CPU is even more
impressive because it would be waking up 100 times a second.

Chris

[ca.portal.admin]

Hi Chris,

Do not understand the foreign language bit.
Do you have PMDC?

If so try option 3.1 and you see RHDCDEAD and it reports CPU time.

Looking at two of our busy systems one shows 75 seconds this one has
been up for 11 days and DCMT D STA SYS reports that it has used 3 hours
and 20 minutes CPU.

We have a task that resets the system and user CPU time to zero and this
runs every night So DCMT D STA SYS is reporting CPU used today.

The other shows 146 seconds this one has been 26 days and so far DCMT D
STA SYS shows 4 hours and 44 minutes CPU.

Now assuming that PMDC has got its numbers correct it seems that
RDHCDEAD is not a large or even a significant overhead.

Sorry should have said we have the Deadlock Detection Interval set to 1.

Pete

[ca.portal.admin]

Hi Lutz,
You're more or less on the right track.
Running a batch job with the interval at 2 different values AND running
some sort of monitor for CPU usage, will give one an idea of how much
overhead the deadlock detection process will use. However, you have to
have the same task load in both tests in order to make the numbers
relate. This is because the deadlock detector has to look around and
collect information about all tasks that are waiting at the time it
wakes up. If, on one interval there are 3 tasks and on another interval
there are 17 tasks, the CPU used will be different. How much different,
I can't even begin to guestimate.
As to task type, it is a DC task. This is why it can only gain control
when the currently active task waits. (Have to watch out for runaway
tasks.) The deadlock detection processed was removed from dispatcher
with the development of R12. The deadlock detection interval simply
controls how often the deadlock detector wakes up and looks around for a
deadlock. For sites that have a large task load there is even an ability
to change the scale of the deadlock interval into 100ths (I believe it
is 100ths) of a second. By using this option, a deadlock detection
interval of 100 would be the same as a deadlock detection interval of 1,
with the option turned off.
Chuck

[ca.portal.admin]

Hi Lutz,
You're more or less on the right track.
Running a batch job with the interval at 2 different values AND running
some sort of monitor for CPU usage, will give one an idea of how much
overhead the deadlock detection process will use. However, you have to
have the same task load in both tests in order to make the numbers
relate. This is because the deadlock detector has to look around and
collect information about all tasks that are waiting at the time it
wakes up. If, on one interval there are 3 tasks and on another interval
there are 17 tasks, the CPU used will be different. How much different,
I can't even begin to guestimate.
As to task type, it is a DC task. This is why it can only gain control
when the currently active task waits. (Have to watch out for runaway
tasks.) The deadlock detection processed was removed from dispatcher
with the development of R12. The deadlock detection interval simply
controls how often the deadlock detector wakes up and looks around for a
deadlock. For sites that have a large task load there is even an ability
to change the scale of the deadlock interval into 100ths (I believe it
is 100ths) of a second. By using this option, a deadlock detection
interval of 100 would be the same as a deadlock detection interval of 1,
with the option turned off.
Chuck

[ca.portal.admin]

Hi Lutz,
You're more or less on the right track.
Running a batch job with the interval at 2 different values AND running
some sort of monitor for CPU usage, will give one an idea of how much
overhead the deadlock detection process will use. However, you have to
have the same task load in both tests in order to make the numbers
relate. This is because the deadlock detector has to look around and
collect information about all tasks that are waiting at the time it
wakes up. If, on one interval there are 3 tasks and on another interval
there are 17 tasks, the CPU used will be different. How much different,
I can't even begin to guestimate.
As to task type, it is a DC task. This is why it can only gain control
when the currently active task waits. (Have to watch out for runaway
tasks.) The deadlock detection processed was removed from dispatcher
with the development of R12. The deadlock detection interval simply
controls how often the deadlock detector wakes up and looks around for a
deadlock. For sites that have a large task load there is even an ability
to change the scale of the deadlock interval into 100ths (I believe it
is 100ths) of a second. By using this option, a deadlock detection
interval of 100 would be the same as a deadlock detection interval of 1,
with the option turned off.
Chuck

[ca.portal.admin]

Hi Lutz,
You're more or less on the right track.
Running a batch job with the interval at 2 different values AND running
some sort of monitor for CPU usage, will give one an idea of how much
overhead the deadlock detection process will use. However, you have to
have the same task load in both tests in order to make the numbers
relate. This is because the deadlock detector has to look around and
collect information about all tasks that are waiting at the time it
wakes up. If, on one interval there are 3 tasks and on another interval
there are 17 tasks, the CPU used will be different. How much different,
I can't even begin to guestimate.
As to task type, it is a DC task. This is why it can only gain control
when the currently active task waits. (Have to watch out for runaway
tasks.) The deadlock detection processed was removed from dispatcher
with the development of R12. The deadlock detection interval simply
controls how often the deadlock detector wakes up and looks around for a
deadlock. For sites that have a large task load there is even an ability
to change the scale of the deadlock interval into 100ths (I believe it
is 100ths) of a second. By using this option, a deadlock detection
interval of 100 would be the same as a deadlock detection interval of 1,
with the option turned off.
Chuck