>There are existing search/update models in which the "runner" performs its >search using only block-concurrent instructions (such as L) without >serialization and then checks later whether a retry is needed. A good example is >IEANTRT. That code is FAST because the "retrieve" function never serializes >against the "update" function.
All such techniques that I know of rely on the fact that the blocks can *never* be deleted. With transactions, you can accommodate deletion. This is true for name/token and even CPOOL (which doesn't even need to "run" just look at the first element's forward pointer). Peter Relson z/OS Core Technology Design
