Re: HSM Compaction question(s)
David, You may be disappointed. When a dataset on Primary is eligible for ML2 it will be migrated there directly during Primary space management. Secondary space management will move datasets on Ml1 to ML2 if they have aged to their ML2 criteria. There is nothing that forces migration to take a detour to ML1. If you are DASD rich then I expect to see a fair amount of ML1 and ML2 activity during Primary Space Management when volumes occasionally dip below their space thresholds. If you have the traditional camel's hump CPU profile, then you would normally try an schedule Primary and secondary space management in one of the troughs of activity. If it is already running that way, and not driving peak utilization then I'd be wondering what the actual saving is. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of > O'Brien, David W. (NIH/CIT) [C] > Sent: Thursday, March 24, 2011 6:22 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: [IBM-MAIN] HSM Compaction question(s) > > John, Ron, Adam, > > Thanks for the feedback. Compaction has been turned off, ML1 to ML2 criteria > has been reduced. > Hopefully the performance folks will stop complaining about HSM, unlikely. > > To answer Ron's question about, 'why use ML1 at all'. We have abundant DASD, > tape drives not so much. I'd prefer to bundle data movement to ML2 to the > Secondary Space Mgt. window. I'm still cogitating whether or not that is a > valid concern. > > Regards, > Dave O'Brien > > > -Original Message- > From: Donnelly, John P [mailto:john.p.donne...@nsc.com] > Sent: Wednesday, March 23, 2011 10:59 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: HSM Compaction question(s) > > We are DASD rich and CYCLEs poor, therefore NOCOMPaction anything... > > John Donnelly > National Semiconductor Corporation > 2900 Semiconductor Drive > Santa Clara, CA 95051 > > 408-721-5640 > 408-470-8364 Cell > cjp...@nsc.com > > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of > O'Brien, David W. (NIH/CIT) [C] > Sent: Wednesday, March 23, 2011 5:46 AM > To: IBM-MAIN@bama.ua.edu > Subject: HSM Compaction question(s) > > The system I inherited has compaction turned on for Dasdmigrate and > Dasdbackup. We notice spikes in CPU utilization during HSM Migration whether > it is manual or interval. Since we have DASD in abundance while CPU cycles are > sometimes in short supply, I'm considering turning off compaction to save on > overhead. > > My question to the group is whether the HSM users out there have compaction > turned on or not and if yes what is your COMPACTPERCENT setting? > Does anyone know of any downsides to turning off compaction, other than a > larger ML1 pool? > > David O'Brien > NIH Contractor > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HSM Compaction question(s)
I was going to go even further - why not just get rid of ML1 and add all of those volumes to your primary storage groups? I think you will need one or two ML1 volumes for VTOCs for backups, etc..., but I would get rid of the ML1 volumes to reduce cycles - and all migration would be straight to tape. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ron Hawkins Sent: Thursday, March 24, 2011 5:17 AM To: IBM-MAIN@bama.ua.edu Subject: Re: HSM Compaction question(s) John, If you are cycle poor, why would you bother migrating something to ML1 when it will use the same amount of space, and cost the same to store? Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of > Donnelly, John P > Sent: Wednesday, March 23, 2011 7:59 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: [IBM-MAIN] HSM Compaction question(s) > > We are DASD rich and CYCLEs poor, therefore NOCOMPaction anything... > > John Donnelly > National Semiconductor Corporation > 2900 Semiconductor Drive > Santa Clara, CA 95051 > > 408-721-5640 > 408-470-8364 Cell > cjp...@nsc.com > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HSM Compaction question(s)
John, Ron, Adam, Thanks for the feedback. Compaction has been turned off, ML1 to ML2 criteria has been reduced. Hopefully the performance folks will stop complaining about HSM, unlikely. To answer Ron's question about, 'why use ML1 at all'. We have abundant DASD, tape drives not so much. I'd prefer to bundle data movement to ML2 to the Secondary Space Mgt. window. I'm still cogitating whether or not that is a valid concern. Regards, Dave O'Brien -Original Message- From: Donnelly, John P [mailto:john.p.donne...@nsc.com] Sent: Wednesday, March 23, 2011 10:59 AM To: IBM-MAIN@bama.ua.edu Subject: Re: HSM Compaction question(s) We are DASD rich and CYCLEs poor, therefore NOCOMPaction anything... John Donnelly National Semiconductor Corporation 2900 Semiconductor Drive Santa Clara, CA 95051 408-721-5640 408-470-8364 Cell cjp...@nsc.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Wednesday, March 23, 2011 5:46 AM To: IBM-MAIN@bama.ua.edu Subject: HSM Compaction question(s) The system I inherited has compaction turned on for Dasdmigrate and Dasdbackup. We notice spikes in CPU utilization during HSM Migration whether it is manual or interval. Since we have DASD in abundance while CPU cycles are sometimes in short supply, I'm considering turning off compaction to save on overhead. My question to the group is whether the HSM users out there have compaction turned on or not and if yes what is your COMPACTPERCENT setting? Does anyone know of any downsides to turning off compaction, other than a larger ML1 pool? David O'Brien NIH Contractor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HSM Compaction question(s)
John, If you are cycle poor, why would you bother migrating something to ML1 when it will use the same amount of space, and cost the same to store? Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of > Donnelly, John P > Sent: Wednesday, March 23, 2011 7:59 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: [IBM-MAIN] HSM Compaction question(s) > > We are DASD rich and CYCLEs poor, therefore NOCOMPaction anything... > > John Donnelly > National Semiconductor Corporation > 2900 Semiconductor Drive > Santa Clara, CA 95051 > > 408-721-5640 > 408-470-8364 Cell > cjp...@nsc.com > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HSM Compaction question(s)
We are DASD rich and CYCLEs poor, therefore NOCOMPaction anything... John Donnelly National Semiconductor Corporation 2900 Semiconductor Drive Santa Clara, CA 95051 408-721-5640 408-470-8364 Cell cjp...@nsc.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Wednesday, March 23, 2011 5:46 AM To: IBM-MAIN@bama.ua.edu Subject: HSM Compaction question(s) The system I inherited has compaction turned on for Dasdmigrate and Dasdbackup. We notice spikes in CPU utilization during HSM Migration whether it is manual or interval. Since we have DASD in abundance while CPU cycles are sometimes in short supply, I'm considering turning off compaction to save on overhead. My question to the group is whether the HSM users out there have compaction turned on or not and if yes what is your COMPACTPERCENT setting? Does anyone know of any downsides to turning off compaction, other than a larger ML1 pool? David O'Brien NIH Contractor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HSM Compaction question(s)
David, Where your Primary and ML1 disk are on the same disk platform, basically costing the same $/GB, the saving realized from ML1 is the fact that it is compressed. If compression reduces the size of migrated datasets by 75% than an aggressive ML1 policy can reduce the cost of idle data by up to 75%. ML2 is usually on tape, so the savings are in the media, and tape is doing its own compression so in most cases ML2 is not compressed. As you noticed, there is no free lunch because compression uses cycles, and if DFSMShsm ML1 activity is driving your peak CPU the net savings of ML1 may not be worth it. If you are going to turn off ML1 compression then I would suggest that your either (a) change your ML1 policies to migrate less data, because there is no point putting a dataset on ML1 if it uses the same space; or (b) use a cheaper storage platform for Ml1, like SATA drives, so you still realize a saving when you migrate to ML1. You've probably guessed that when you turn of compression you will need to increase the size of ML1 by 300 - 400%. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of > O'Brien, David W. (NIH/CIT) [C] > Sent: Wednesday, March 23, 2011 5:46 AM > To: IBM-MAIN@bama.ua.edu > Subject: [IBM-MAIN] HSM Compaction question(s) > > The system I inherited has compaction turned on for Dasdmigrate and > Dasdbackup. We notice spikes in CPU utilization during HSM Migration whether > it is manual or interval. Since we have DASD in abundance while CPU cycles are > sometimes in short supply, I'm considering turning off compaction to save on > overhead. > > My question to the group is whether the HSM users out there have compaction > turned on or not and if yes what is your COMPACTPERCENT setting? > Does anyone know of any downsides to turning off compaction, other than a > larger ML1 pool? > > David O'Brien > NIH Contractor > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HSM Compaction question(s)
David, A few years ago we totally eliminated ML1 and started directing our migration directly to ML2. We just kept the data on ML0 for the same amount of time that we would have had the data on ML0 and ML1 - thus we increased the disk in our storage pools. We also turned off compaction in DFHSM and let the tape controllers do the compaction. One other thing we did was to implement the ARCMDEXT and not migrate datasets that were smaller than 10MB for 100 days. We saw a 38% decrease in DFHSM CPU utilization when we implemented these changes. ThanksRick -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Wednesday, March 23, 2011 7:46 AM To: IBM-MAIN@bama.ua.edu Subject: HSM Compaction question(s) The system I inherited has compaction turned on for Dasdmigrate and Dasdbackup. We notice spikes in CPU utilization during HSM Migration whether it is manual or interval. Since we have DASD in abundance while CPU cycles are sometimes in short supply, I'm considering turning off compaction to save on overhead. My question to the group is whether the HSM users out there have compaction turned on or not and if yes what is your COMPACTPERCENT setting? Does anyone know of any downsides to turning off compaction, other than a larger ML1 pool? David O'Brien NIH Contractor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
HSM Compaction question(s)
The system I inherited has compaction turned on for Dasdmigrate and Dasdbackup. We notice spikes in CPU utilization during HSM Migration whether it is manual or interval. Since we have DASD in abundance while CPU cycles are sometimes in short supply, I'm considering turning off compaction to save on overhead. My question to the group is whether the HSM users out there have compaction turned on or not and if yes what is your COMPACTPERCENT setting? Does anyone know of any downsides to turning off compaction, other than a larger ML1 pool? David O'Brien NIH Contractor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
