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:[email protected]] On Behalf Of > Bill Fairchild > Sent: Monday, January 23, 2012 11:21 AM > To: [email protected] > Subject: Re: [IBM-MAIN] Going from mod-3 to mod9 > > In <[email protected]>, on > 01/23/2012 > at 09:08 AM, "Staller, Allan" <[email protected]> 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 > [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
