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.
Thanks....Rick -----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
