That is true. If I can not be sure about a specific track I will take the worse case. That can be until one cylinder. The simulator is many thousands of code and I made it the best and the efficient I can.
Good point Bill. Shai On Wed, Nov 3, 2010 at 5:14 AM, Bill Fairchild <[email protected]> wrote: > 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 > ---------------------------------------------------------------------- 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
