Thanks, Ron. I didn't know about the 3990-3's ability to process two cache hits simultaneously. I would assume, though, that both I/Os would have to be read only. And all that the controller has to do to test for read-only is to test two bits in the File Mask byte.
The pending time I described existed with the introduction of S/370-X/A in the early 1980s for all attached DASDs, I believe. The single threading with MDA is necessary if there is any possibility that one I/O can alter data that another active I/O to the same logical device might need to read. This is controlled in EMC's 2105 microcode by single-threading all I/Os to device X that have at least one track in common in their defined extent track ranges AND if any of the I/Os with the extent overlap is not read-only. As long as all the I/Os to device X are read-only, then an infinite number of them can run simultaneously with no worries. But as soon as an I/O is found to be non-read-only, then its track range is used for single-threading against all other I/Os running that have at least one track in both I/O's track ranges. E.g., if I/O (1) from system (A) to device X has a track range of 00000000-5678000E and is read-only but I/O (2) from system (B) to device X has a track range of 5678000E-56790000 and also has the potential to write data somewhere within that range of only two tracks, then both of these I/Os must be single-threaded and executed in the same sequence in which they entered the control unit. At least this is how EMC's patent application describes how their equivalent MDA microcode works. And this single-threading is not forced upon the I/Os by sibling pend but rather is required in order to guarantee data integrity regardless of how many siblings or internal paths there are. Bill Fairchild -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ron Hawkins Sent: Friday, January 27, 2012 9:17 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Going from mod-3 to mod9 Bill, You said " If the shared control unit attached to this device is not an IBM 2105 SHARK (vintage ca. 2000), plug-compatible equivalent, or some successor technology, then image A's I/O will not really be started until image B's already started I/O ends." Logical Device allegiance was introduced in the 3990-3 would allow ImageA and ImageB to process two cache hits concurrently providing they were not on the same track. My understanding is that the pending time you described occurs when the both systems tried to access the disk drives in 3990 controller emulation. Multiple Device Allegiance (MDA) was developed to allow concurrent access to multiple disk drives that make up the logical volume. There's no need single threading IO requests from multiple systems when there's four or more disk drives that can handle the IO without sibling pend. HDS had a function called the multi-job IO feature that would allow up to four LPARs to access the HDD for a logical volume concurrently. This was introduced in the 7700E, but they had to rewrite it in order to support MDA and PAV (9980V I think). MDA works without a PAV license. Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of > Bill Fairchild > Sent: Monday, January 23, 2012 11:21 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: [IBM-MAIN] Going from mod-3 to mod9 > > In <45e5f2f45d7878458ee5ca679697335502e25...@usdaexch01.kbm1.loc>, on > 01/23/2012 > at 09:08 AM, "Staller, Allan" <allan.stal...@kbmg.com> said: > > >From the viewpoint of the Operating System, you now have 3 times as > >much data behind the actuator on Mod-9's as Mod-3's. > >If the Operating system *thinks* the device is busy, the IO is queued > >off the UCB and never even tried until it comes to head of queue. > > You MIGHT have up to three times as much data behind the actuator. > That depends on how fully loaded the three mod-3s are which are to be > merged onto > the same single mod-9; i.e., it depends on which three mod-3s you > choose to > merge together. > > If all data sets on all volumes are equally and randomly accessed, > then you > will have three times as much requirement to access the new mod-9 as > any of > the three mod-3s had which were merged. However, most data centers > have highly skewed access patterns. 80% of the actuators might have > only 20% of > the total I/O workload. Which means your volumes are almost certainly > NOT equally and randomly accessed. You have some volumes that are > almost never > accessed and some others that are accessed all the time. > > When z/OS starts in I/O on DASD device xxxx, z/OS turns on a flag bit > in the > UCB for that device that indicates that this particular z/OS image has started > an I/O on that device. But if the device is shared, then another z/OS image > may have already started an I/O on the same device, turned that same device's > UCB flag bit on in its copy of the UCB for the device (which might be device > yyyy on the other image), and not informed any of the other sharing > z/OS images that it is now doing I/O on that shared device. So when > image A tests > its private copy of the flag bit and finds it off, that does not necessarily > mean that the device is unbusy. Image A doesn't care, however. It > starts the > I/O and turns the bit on. If the shared control unit attached to this device > is not an IBM 2105 SHARK (vintage ca. 2000), plug-compatible > equivalent, or > some successor technology, then image A's I/O will not really be > started until > image B's already started I/O ends. This will show up on ima! > ge A as a spike in device pending time, not in IOSQ time. The 2105 > and newer > technology have the ability to let multiple I/O requests from multiple sharing > systems run simultaneously against the same device as long as there is > no conflict between any of the simultaneous I/Os involving both reads > and writes > for the same range of tracks. > > The only way to know what will probably happen is to do I/O > measurement on your current mod-3 workload. If you don't see much > IOSQ time now, then you > will see "not much" multiplied by three after merging. How much is > not much > and/or is negligible is up to you to decide. You might also get an > idea as to > how to merge volumes together based on their individual IOSQ times; > e.g., merge the one with the highest IOSQ time now with the two mod-3s > that now have > the lowest average IOSQ times. After merging them, measure again for > IOSQ time. Only if you have "excessive" IOSQ time, where how much is > excessive is > up to you to decide, would you need to consider using PAV devices. > > Currently z/OS's I/O Supervisor has no knowledge of the real RAID architecture > backing the virtual SLED, so many of the classic performance- and > space- related bottlenecks can theoretically still occur. > > Bill Fairchild > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to > lists...@bama.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
