In a message dated 4/19/2007 9:19:02 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: >> commit is one of them that >> will force the destage of tracks to disk. >I am 99.99% sure this is not true in HDS RAID, and I'd wager a few bucks >that EMC and IBM do not honour a request like this either. The destage would >likely be queued and occur asynchronous to host IO requests. The IBM 2105 (ESS) allows a commit order to work either synchronously or asynchronously by user request (user = whatever authorized MVS component built the channel program). Commit can work on modified CFW data only or modified CFW and DFW data, but the commit function only works on tracks that are within the extent range specified by the user (same guy). Thus commit can be confined to a single data set as in CLOSE, all data sets in a job step, or possibly the entire volume. There could theoretically be thousands of changed tracks needing to be destaged, and this could take a very long time, which is why the asynchronous option exists. HDS, EMC, and all other compatible vendors must supply microcode that supports all of these possibilities if they intend to be compatible. The commit function was available on older control units, and it worked as advertised. Some of these options are ignored now by newer controllers, such as certain caching algorithms on the 9340, but the reference book states specifically that such a request is ignored. Since the 2105 book does not say the synchronous option is ignored, I cannot believe that IBM would build 2105 microcode that would ignore it. If the control unit were to ignore asynchronous requests and always destage synchronously, then there is no danger that data will be hosed, but there could easily be serious performance degradation of software in the host system which could possibly result in ABENDs or unnecessary error recovery due to I/O timeouts. If the control unit were to ignore synchronous requests and always destage asynchronously, then I believe it is possible for non-destaged tracks to be overwritten by another application if the tracks are deallocated, reallocated to another application, and then written onto before being destaged. Control units have no knowledge of VTOCs, allocated extents, other MVS metadata, and when ownership of a track is released by software process Y and then picked up by process Z. There is already a flag bit in control unit working storage for each track to indicate that the track has been changed, which also means it must be destaged unless it is also CFW. There would also have to be another bit for each track to show that that track is a CFW track. If both are on, then the track would never be destaged unless (1) the track slot needs to be reused or (2) a commit order occurs. The only question then is does vendor X's microcode prevent changed CFW data to be changed again before being destaged in a commit situation. One would hope so. I don't know that answer. An experiment could be performed to determine how it works on vendor X's box. If the changed CFW track is not allowed to be rechanged before being destaged when commit is happening and an attempt is made to change the track again, then the control unit must destage this one track immediately on an emergency basis in order to minimize the time that the application must wait. The 2105 book does not describe this situation, so we don't know definitively. To support this situation, a third bit would be needed for each track. When you have almost one million tracks on a mod-54 volume and a vast number of mod-54s within one subsystem, each such bit is parceled out very cautiously. Using separate bits is just one possible implementation. Other implementations would avoid using more than one bit, but then additional physical track metadata must be saved somewhere. Trade-offs are considered by the microcode engineers. One thing I know for sure - they value data integrity more than anything else. 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
