Shai has said that he understands what the Read Count, Search Key Equal, TIC *-16 loop is doing. His problem is that when simulating how that sequence works, he cannot know, without also reading the tracks involved (which for performance reasons he doesn't want to do) which track, if any, has the key that will cause the loop to end, which will then presumably be the only track in the range of tracks being searched that will be accessed by a write command coming after the search/TIC pair. Thus he cannot know which track to replicate. One way to solve this problem is to replicate all the tracks within the range being searched, which will depend on whether the chain is operating in CKD or ECKD mode and also on the current file mask.
When in CKD mode, the maximum number of tracks that can be in a multi-track search operation is however many tracks constitute one full cylinder. When in ECKD mode, the maximum number of tracks that can be accessed in any multi-track operation is always two, the track where the operation begins and one track beyond that. In all these cases, if the search fails after accessing all possible tracks in the range allowed, the channel program will end with a Record Not Found error, which may then cause the operating system to redrive the channel program on a new cylinder or a new range of tracks. Presumably his code would also intercept such a redrive operation with the new range of tracks visible. The problem here is that a very large number of tracks may have to be searched before the search command is successful, and he doesn't want to have to replicate any more tracks than have really been changed by a write command coming immediately after the Search/TIC. A real DASD will never have more than one track written to, but Shai's difficulty lies in knowing which one track to replicate. Bill Fairchild Rocket Software -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Rick Fochtman Sent: Tuesday, November 02, 2010 7:33 PM To: [email protected] Subject: Re: The replication feature. On real hardware, the READ_COUNT will give you the address of the record whose key is being compared by the next CCW. It's a sequence that is heavily used in searches of non-indexed VTOCs. Rick ------------------------------------------ shai hess wrote: >Yes, I know it and I support it. >But be aware that I can not see the result of the READ_COUNT because I take >control before the IO is really done to the real device. > >Shai > >On Mon, Nov 1, 2010 at 12:27 PM, Rick Fochtman <[email protected]> wrote: > > > >>---------------------------------------<snip>----------------------------------- >> >> >>A few words on replication. >> >> >>>The standard replication is sending CCWS to all controller which >>>have mirrors disks. Sometime controller send data to other controller to >>>sync the data between all of them. >>>In this process each controller emulates the CCWS and by that create the >>>same data as the source disk. In this case the search key is very easy to >>>implement. >>> >>>MFNetDisk because of the slow media of TCP do something else. It is >>>analyze >>>the CCW in memory without accessing the source disk data. That is why it >>>is >>>hard to process the search key without access the data in the disk. After >>>process the CCW it is decide what tracks need to be ReSync in the mirrors >>>of >>>the source disks. This process is complicate process especially for search >>>key CCW. Using this processing, MFNetDisk never block the real disk but >>>the >>>minus is that this is ASync processing meaning that if there is crash in >>>MF, >>>the mirror may be not fully Sync with the source disk. the MFNetDisk >>>replication can be good if you want to create Sync point or backup of the >>>real disk in specific time where you can validate that the process of >>>ReSync >>>is done completely without updating the source disks for short time until >>>the ReSync is totally over. This is called Sync Point where the mirrors is >>>fully Sync with the real disk. >>> >>>About the MFNetDisk emulation. Each CCW is sent to the PC which access the >>>data in the emulate disks and easily can process any CCW include serach >>>key >>>and all other CCWS. >>> >>> >>> >>> >>-------------------------------------------<unsnip>------------------------------------- >>Shai, it's entirely acceptyable to use a READ COUNT CCW before the SEARCH >>KEY HIGH-OR-EQUAL CCW. >> >>READ COUNT >>SEARCH KEY HIGH-OR-EQUAL >>TIC *-16 (Back to the READ COUNT >>READY DATA (or WRITE DATA, as needed) >> >>Rick >> >> >>---------------------------------------------------------------------- >>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 >> >> >> > >---------------------------------------------------------------------- >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 >. > > > ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
