-----Original Message----- From: Kenneth Wilkerson [mailto:redb...@austin.rr.com] Sent: Friday, November 08, 2013 8:46 AM To: 'IBM Mainframe Discussion List' Subject: RE: Serialization without Enque
>I really don't see the big deal with an 0c4 in this scenario (should happen rarely) You misunderstood my point. You could use PLO to serialize a chain even if the areas are released as they are deleted provided you always use PLO Compare and Load to load the pointers and recovery sets a retry to re-drive the process. As long as the count is updated each time you do a delete (and release), if the delete occurs while some other management function is being performed, the PLO Compare and Load will force the redrive either by CC or 0c4. If the storage had been reallocated but still in the same key, the PLO would fail because the count has changed. PLO may fetch operands before the lock and memory serialization so an 0c4 can occur on the PLO Compare and Load. Either way, the PLO does not store so there is never an overlay. I would never design an application to use PLO in this fashion. However, if I had an existing application, I find this methodology more desirable than getting a CMS lock everywhere I access the chain. I stand by my statement that you can serialize 99+% of all scenarios using PLO and that P:LO serialization is much more desirable than locks. If this were not the case, why bother creating the transactional execution facility? Kenneth -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Friday, November 08, 2013 8:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Serialization without Enque >applicable to 99%+ of all serialization scenarios you encounter To be frank, you might not have very complex serialization requirements. Also, using PLO when CS,CSG,CDS,CDSG would do is a significant waste of cycles. For the cases I have seen within our code, uses of PLO (in the cases where it is not better to use something simpler) are a tiny percentage of our serialization needs. >When the updating process wakes up S0C4! Using PLO to update a free queue, as is the case with CPOOL and its CDS-based free-queue protocol, requires that the queue elements *never* be freed (unless you like potentially blowing up or, worse, overlaying something you didn't intend to write into). Perhaps this is not well understood. >I really don't see the big deal with an 0c4 in this scenario (should happen rarely) That's a scary statement. If you get an 0C4 you could probably deal with it. The real risk is the case where you don't get an 0C4 because the storage was re-allocated and used for something else and now it does not program check but overlays something. >I think I figured out a solution: There are a lot of details missing in what was shown, but if you want my honest suspicion, it's that if this is a "free queue" type of protocol, it will not work. The reason that the free queue protocol needs a sequence number is because even if the header "matches", the values that you need to put into your new element for the "next" and/or "previous" may no longer be correct due to a set of additional asynchronous operations. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
