<snip> You stated that I could not get the CML lock if the local lock is help. Is there a problem getting the local lock if the CML lock is held? </snip>
The CML lock is the Local Lock of an address space other than current home. Hence there are as many CML locks as there are address spaces. The Local Lock is *your* local and is everybody else's CML. Since the CML and the Local Lock exist at the same locking hierarchy and the rule says that if you hold one lock you can only obtain another lock higher in the hierarchy, then you cannot hold both the Local Lock and some CML. But I want to emphasize what Shmuel Metz said when he wrote that holding a lock only affords protection from multiple updates if everybody who wants to update that storage agrees to, and holds the locks in question. If you do not know what program (other than your own) is updating this storage then locking is not going to help you. If you know that the other program is using CDS or PLO, they will still be allowed to issue these instructions even though you hold the CMS lock. All CMS does is keep any other task in any other address space from holding the CMS lock. It's up to you to establish the rules for storage update and then abide by them. If you don't know what other program is going to update this same CSA storage and you want to protect against multiple simultaneous updates you'll have to go to far greater lengths than the CMS lock, CDS or PLO. I think I'll say no more about this type of protection unless you want me to. If only other instances of *your* program are trying to update this storage, then you can design your own locking mechanism. I agree with everybody who has said that PLO (or CDS) is the better way to go than using system locks. If you've had trouble with PLO or CDS, perhaps there was something not quite right in the way you used them? I'm not saying there was, but just making a observation that perhaps there was. Andy Coburn -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Donald Likens Sent: Wednesday, August 10, 2011 9:46 AM To: [email protected] Subject: Re: SETLOCK in IEFU85 I was planning to check the return code of the obtain lock to determine if I should release it. I do not think it is as elegant as your approach but I think a little easier. Does anyone see a flaw in this idea? You stated that I could not get the CML lock if the local lock is help. Is there a problem getting the local lock if the CML lock is held? So my logoc will look like the following: SETLOCK OBTAIN,TYPE=LOCAL, LOCAL LOCK set localrc = r15 SETLOCK OBTAIN,TYPE=CMS, CROSS-MEMORY SERVICES X set cmsrc = r15 Update my CSA buffer if cmsrc = 0 setlock release,type=cms if localrc = 0 setlock release,type=local ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
