Appropriate / safe is in the eye of the beholder. I personally see serialization as reducing the risks as much as possible. To eliminate the risk, you would have to orphan the entry. There were recommendations of moving to a free chain and reusing them. This has risks too because you simply don't know when everyone has finished with it. Only maintaining a use count would ensure it's no longer in use but that has risks too. We do what we have must to get the job done so we make the exposure as small as we possibly can. Take for example: L R2,QUEUE L R3,NEXT_ENTRY CS R2,R3,QUEUE New queue head While this seems bullet proof, it's not. If there is a long delay between between the L instructions then next entry could have been freed causing an abend. While the delay is very unlikely, it is still a possiblity (e.g. swapout after first "L"). This example is just removing the first entry. If you try to remove an entry in the middle of the chain, you run a larger risk.
Some of the techniques we use to minimize risk: 1. Abend recovery 2. don't overload the entry - only contains shared information. 3. Place entry on a timeout queue before placing on a free queue or freeing. 4. Copy the entry to workarea - reduces reference time of actual entry 5. Eyecatchers that can be verified. 6. Unique identifier for each entry that can be verified. 7. Turn off interrupts. This is not a complete list. It's only meant to give you an idea of how complex the process can be. You need to think about the small details. Even the support staff is considered a risk because they may not fully understand the serialization requirements you implement. Jon Perryman. >________________________________ > From: Scott Ford <[email protected]> > > >Can you guys tell me what you consider the appropriate / safe way to >enqueue-de queue a resource being shared > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
