<In order that processes merely reading the list not perceive a corrupt> <state, readers must issue an ENQ SHR on the same resource on which updaters
<issue an ENQ EXC. Is this not sufficient?> I agree with you concerning the ENQ SHR and ENQ EXC for protection. These do protect the queue from simultaneous update from different dispatchable units of work (TASK or SRB). The case I was discussing was the one where, while holding the ENQ EXC the program needs multiple different instructions to update the queue. When there are a number of STORE instructions needed to perform the queue manipulation this situation can exist. I'm not talking about single linked lists now, but dual linked lists which cannot be processed by either CS or CDS because two or more disjoint areas of storage must be updated to complete the entry-add or entry-delete operation. And the case I'm discussing is when this routine is in a program which can be cancelled or can suffer some other external abend, maybe a mother task abend. Things like that. And due to bad luck the program manipulating the queue was interrupted after one STORE had been done but a second or third one had not. It's the very bad luck that seems to only happen at 3:00 AM. And what's more it's when the queue must remain intact after this abend. Not a problem if the queue is local to the program in question and after an abend the program can be restarted. I'm talking about a queue that is in common storage and the routine processing the queue is called from a "user" program and is running under that "user" program's ASCB/TCB - For instance, a stacking non-space switch PC routin. My point is that, yes, the ENQ you describe is absolutely necessary but it isn't enough to keep the queue from corruption if an abend occurs during the update processing. Corruption in my case always seemed to be an entry that ended up pointing to itself. This isn't a case that most code would bother checking for and mine didn't. I think it would be very hard, and very inefficient, if every time the queue were accessed that a full verification had to occur. Better to see to it that the queue remains valid. Did this explain my position? I'm afraid I've said either too much or too little. Andy Coburn
