CA IDMS

Expand all | Collapse all

Deadlock Detection Interval

ca.portal.admin10-04-2007 10:46 AM

ca.portal.admin10-04-2007 10:46 AM

  • 1.  Deadlock Detection Interval

    Posted 10-04-2007 02:37 AM
    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 +41 (0)58 887 4332, Fax +41 (0)58 887 4969
    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
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    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 +41 (0)58 887 4332, Fax +41 (0)58 887 4969
    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
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    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 +61 (0)8 8226 5199
    Facsimile +61 (0)8 8226 5311
    Mobile +61 (0)41 333 1613
    MailTo:cherlet.gary@saugov.sa.gov.au

    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.


  • 2.  Re: Deadlock Detection Interval

    Posted 10-04-2007 03:44 AM
    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


  • 3.  Re: Deadlock Detection Interval

    Posted 10-04-2007 04:30 AM
    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
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

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


  • 4.  Re:Re: Deadlock Detection Interval

    Posted 10-04-2007 05:23 AM
    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
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    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.


  • 5.  Re: Deadlock Detection Interval

    Posted 10-04-2007 05:23 AM
    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
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    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.


  • 6.  Re:Re: Deadlock Detection Interval

    Posted 10-04-2007 05:23 AM
    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
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    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
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    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


  • 7.  Re:Re: Deadlock Detection Interval

    Posted 10-04-2007 05:23 AM
    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
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    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





  • 8.  Re:Re: Deadlock Detection Interval

    Posted 10-04-2007 05:23 AM
    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
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    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.


  • 9.  Re:Re: Deadlock Detection Interval

    Posted 10-04-2007 05:23 AM
    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
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    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


  • 10.  Re: Deadlock Detection Interval

    Posted 10-04-2007 06:36 AM
    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.


  • 11.  Re: Deadlock Detection Interval

    Posted 10-04-2007 10:35 AM
    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
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    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
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    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


  • 12.  Re: Deadlock Detection Interval

    Posted 10-04-2007 10:46 AM
    Es kann manchmal schwierig sein.


  • 13.  Re:Re: Deadlock Detection Interval

    Posted 10-04-2007 10:46 AM
    Es kann manchmal schwierig sein.


  • 14.  Re:Re: Deadlock Detection Interval

    Posted 10-04-2007 11:33 AM
    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
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    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
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    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


  • 15.  Re:Re: Deadlock Detection Interval

    Posted 10-04-2007 11:33 AM
    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
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    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
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    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
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    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.


  • 16.  Re: Deadlock Detection Interval

    Posted 10-04-2007 11:33 AM
    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
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    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


  • 17.  Re: Deadlock Detection Interval

    Posted 10-04-2007 12:19 PM
    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


  • 18.  Re: Deadlock Detection Interval

    Posted 10-04-2007 12:37 PM
    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


  • 19.  Re:Re: Deadlock Detection Interval

    Posted 10-04-2007 12:44 PM
    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


  • 20.  Re:Re: Deadlock Detection Interval

    Posted 10-04-2007 12:44 PM
    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


  • 21.  Re: Deadlock Detection Interval

    Posted 10-04-2007 12:44 PM
    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


  • 22.  Re:Re: Deadlock Detection Interval

    Posted 10-04-2007 12:44 PM
    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