In a message dated 4/19/2007 11:54:15 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: >I don't follow you here Bill. Of course the control unit doesn't know about any logical data structures. It does, however, have to keep track of where all data is located. If there is a copy of a track in cache, it has to know about that and always ensure that the correct copy is updated or returned. The fact that there has been a request to destage the track from cache does not alter that. That's why I said that I believe it is possible, rather than being dogmatic about it, for the data to be corrupted. I could be wrong, too. I then explained in a later paragraph how the data might be corrupted depending on what the microcode does in the specific situation of (1) a track in cache has been changed, (2) this track is volatile CFW data, (3) the track has not yet been destaged, (4) the track must be destaged because of a commit order, (5) a large number of other CFW tracks are being destaged (or anything else is happening which greatly delays the destaging of this one track), and (6) an attempt is made to alter this same track before it has been destaged. The intended nature of CFW is that the data is volatile and can be easily recreated. I was musing on how the microcode might behave (or maybe misbehave) in the worst case, and on possible reasons why synchronous commit requests could not arbitrarily be replaced with asynchronous. When about to alter the data in cache for this hypothetical rewrite, which test is made first - is it CFW (and thus volatile) or must it be destaged due to a commit order? Microcode engineers should envision every possible scenario when designing microcode logic. Microcoders are human, subject to making errors, and build microcode with unintentional bugs like all the rest of us. I would think this scenario is difficult to test. This is the only scenario I could imagine that shows that synchronous requests could not always be replaced with asynchronous. If the commit-destage test is made first, then there is no exposure in this one scenario. Bill Fairchild Plainfield, IL
************************************** See what's free at http://www.aol.com. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
