Yes, when I read "what happens when a parallel task deletes my data while I'm using it", I think, maybe better not to allow that to happen. The whole list might have been logically deleted "behind you" amongst many other possibilities, and it doesn't need an interrupt. So I offered my suggestion that one typically needs to serialize over the whole process until one has "used" the data in such a case. Or avoid such a situation, e.g. by marking an object in-use/free or whatever (which will still need serialization, of course). But obviously pointless for me to pursue the matter, interesting as it is.
-----Ursprüngliche Nachricht----- Von: IBM Mainframe Assembler List [mailto:[email protected]] Im Auftrag von Peter Relson Gesendet: Samstag, 22. September 2012 15:49 An: [email protected] Betreff: Re: The Transaction state (was Model 2827 New Instructions) >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
