David, It is not necessarily a bad thing to disperse your allocations across many volumes, especially if whoever sets up your storage makes sure that there is advantage to it. Sibling pend - contention for spindle(s) - is still a problem and having practices that reduce skew is always a good thing. Consolidating IO from 15-20 mod 3s onto one mod 54 may not be a good idea if you are dropping the number of spindles from 100+ down to 8. YMMV.
Allocation will massage the EDL so that that new datasets do not cluster on one volume that makes it way to the top of the list based on performance and space. If a jobstep allocate 5 new datasets in a STORGRUP and they will end up on 5 different volumes. With good practice in setting up your array groups it means that this one job may be able to access 5 different array groups, rather than be skewed to a small number of devices. Your users may be using Guaranteed Space to artificially create this affect when it is built into the system: in that case I would encourage them not to fight the system. A common problem is to grow a STORGRUP by adding one array group and then assigning most or all of the volumes to that STORGRUP. If you add 8 new 300GB drives as 7D+P and pop all 215 new 3390-9 into the same new STORGRUP, then a lot of new allocations will go there and you suddenly have a skewed write problem. This is a problem in IBM, EMC and HDS storage. It is still important to know what the spindles are doing, and use a balanced systems approach to spread them across as many resources as possible. If your users are spreading their work across many volumes in a large pool of large volumes then I would view that as synergy. RMF is not going to tell you much about what is happening at the backend unless you have IBM. The Element Managers for the other vendors (Storage Navigator for HDS) have very detailed Performance Monitors that can tell you exactly what you array groups are doing, and non-disruptively move volumes to less busy array groups as required. If you want to minimize the effects of volume consolidation I mentioned above, then use the widest striping schemes possible from your vendor. Volumes in a USP spread across 32 spindles will handle skew situations much better than using array groups with 4 or 8 spindles. Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Murray M. Robinson > Sent: Tuesday, January 08, 2008 12:35 PM > To: [email protected] > Subject: [IBM-MAIN] Old habits with new DS6000 and DS8000 > > I am finding hard to persuade some old time IBM developers that > planning > to disperse dataset allocation as if they were accessing old discreet > 3390 > disks is a futile effort. Ignoring that with PAV and WLM goal mode and > 3390s only logical and no one really knows were all the pieces are > stored > on the much fewer physical disks emulating thousands of volumes. I > suggest > use SMS without requesting Guaranteed space and placing their datasets > on > specific volumes is not getting through to them. Please help direct me > to > some decent documentation explaining this. Also if anyone knows when > this > technique is still relevant I'd love to know. Also which RMF screen > gives > a good snapshot of IO activity (and caching) > Thanks. > > This e-mail message and any attachments may contain confidential, > proprietary or non-public information. This information is intended > solely for the designated recipient(s). If an addressing or > transmission > error has misdirected this e-mail, please notify the sender immediately > and destroy this e-mail. Any review, dissemination, use or reliance > upon > this information by unintended recipients is prohibited. Any opinions > expressed in this e-mail are those of the author personally. > > Murray Robinson > > ACI Worldwide, Inc. > [EMAIL PROTECTED] > (402)-778-1930 > > ---------------------------------------------------------------------- > 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
