:>> ... the basic advantage of the :>> PLO is that it avoids the need for locks with non-contiguous serialized areas :>> if the retry rate is low.
I agree completely with the statement above and there's another advantage to PLO as well. Say one has the dual-linked list which is manipulated only after obtaining a lock of some sort. ENQ, Latch, local/CML lock, whatever. Just some mechanism which forbids more than one dispatchable unit of work to be in a piece of code at one time. The list is updated with multiple ST instructions but because there is an ENQ in effect there's no exposure. Well there is, and it has bitten me. I've never be overly fond of specifying SMC=STEP on an ENQ macro. Seems dangerous. But even with SMC, if there is any way whatsoever that the routine in question can be interrupted (excluding abends caused by program errors which would be fixed during development) then an interruption caused by (say) a TSO user logging off, will cause one's ESTAEX or ARR recovery routine to be entered. If the interruption occurred while the list was partially updated, and if the ESTAEX recovery routine attempts RETRY, the chain pointers will be corrupt and unless the ESTAEX recovery routine can (with 100% certainty) restore the chains to their original state the corruption will manifest itself later. This is where PLO shines because storage alterations all occur at one time. Hence the chain is always in one of two states: Either all not updated or all updated. Interruptions cannot occur while the chain is mid-update. Andy Coburn
