determining cause of deadlock
Is there any way to determine who was holding a reserve after the fact? I had a situation where systemA was holding an exclusive enq on a catalog but systemB had the volume reserved. The job holding the catalog enq on systemA was cancelled, thus resolving the contention, before I could issue the appropriate commands to determine who was holding the reserve. I'd still like to know, however, who/what was holding the reserve on systemB so I can possibly avoid the problem in the future. systemA is at z/OS 1.7 and systemB is at z/OS 1.4. TIA, Debbie Mitchell -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: determining cause of deadlock
Debbie Mitchell [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Is there any way to determine who was holding a reserve after the fact? I had a situation where systemA was holding an exclusive enq on a catalog but systemB had the volume reserved. The job holding the catalog enq on systemA was cancelled, thus resolving the contention, before I could issue the appropriate commands to determine who was holding the reserve. I'd still like to know, however, who/what was holding the reserve on systemB so I can possibly avoid the problem in the future. systemA is at z/OS 1.7 and systemB is at z/OS 1.4. TIA, Debbie Mitchell Debbie, If both systems are in the same sysplex, you shoud have received messages IOS431I and commands D U,VOL=vv and D GRS,DEV=vv issued automatically on SystemB. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: determining cause of deadlock
After the fact may be more difficult. But the things I would do are: 1) See if there might be any SVC Dumps taken during the time. They may contain information on GRS even if the dump was not specific to this issue. 2) See if there are any LOGREC data produced. Sometimes yes, Sometimes no. 3) Look in SYSLOG (OPERLOG) during the time the Contention messages are produced on both systems. See what batch jobs or other issues might be happening at that time. Sometimes you get lucky and see a process that will give a clue to the issue. Otherwise, definitely put in automation processes that get triggered on the messages you saw and do the D U and D GRS commands. You may also wish to do a F CATALOG command to list the tasks currently in process in the automation. It may show what is being held in the CAS. Lizette -- Is there any way to determine who was holding a reserve after the --fact? I -- had a situation where systemA was holding an exclusive enq on a --catalog but -- systemB had the volume reserved. The job holding the catalog enq on --systemA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: determining cause of deadlock
SMF record type 77 (RMF enqueue activity) may have information about the event. Scott Barry SBBWorks, Inc. Debbie Mitchell [EMAIL PROTECTED] wrote in message news: Is there any way to determine who was holding a reserve after the fact? I had a situation where systemA was holding an exclusive enq on a catalog but systemB had the volume reserved. The job holding the catalog enq on systemA was cancelled, thus resolving the contention, before I could issue the appropriate commands to determine who was holding the reserve. I'd still like to know, however, who/what was holding the reserve on systemB so I can possibly avoid the problem in the future. systemA is at z/OS 1.7 and systemB is at z/OS 1.4. TIA, Debbie Mitchell -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: determining cause of deadlock
On Tue, 1 May 2007 07:22:09 -0500, Debbie Mitchell [EMAIL PROTECTED] wrote: Is there any way to determine who was holding a reserve after the fact? I had a situation where systemA was holding an exclusive enq on a catalog but systemB had the volume reserved. The job holding the catalog enq on systemA was cancelled, thus resolving the contention, before I could issue the appropriate commands to determine who was holding the reserve. I'd still like to know, however, who/what was holding the reserve on systemB so I can possibly avoid the problem in the future. systemA is at z/OS 1.7 and systemB is at z/OS 1.4. TIA, Debbie Mitchell -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html If you are running RMF with ENQ(DETAIL) as an option, you should be able to execute the RMF post-processor with REPORTS(ENQ). This won't tell you exactly what is causing the problem, but it should get you close enough that you can surmise what's going on. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
