Dana, You're correct. This just looks like a one giant pool of 3390-A to z/OS. z/OS is blissfully unaware of where a track is actually stored, similar to how disk arrays have worked for 20 years now except the pieces of a data set may be on different disk tiers based on the activity pf the page.
I wouldn't go as far as to say the controller is "busy" moving pages between tiers, but I wouldn't say it is negligible either. I think what is more important is that occasional access to an inactive or dormant data set does not in itself trigger any page movement between tiers. Neither will any intense activity to a dataset that is predominantly cache hits. It is the back-end IO activity that defines a pages IO history. There are some happy value metrics designed to avoid tier thrashing every time a page crosses an IO/hour threshold. For archiving there is a lot of talk about moving ML1 and ML2 to tiered pools and radically changing the migration intervals. I'm suggesting a practical vision of doing away with ML1 and ML2 altogether. The data is RAID protected - usually RAID-6 - and so the whole backup DFSMShsmbackup requirement and strategy can be reviewed. Ask yourself why do I keep the very last DFSMShsm backup for three years, when I can just as easily keep the very last copy of the data set on a cheap RAID-6 disk array. DFSMShsm may still have a role to play as a dataset backup utility, but why aren’t they going to a tiered pool where they can age out to commodity disk at the page level? Personally I have usually seen DFSMShsm as a backup vehicle for development and TSO data sets, while production applications tend to use FDR, DFSMSdss, etc. Personally I like the idea of using Flashcopy to put a date-time suffixed copy of related datasets into a tiered Storage Group. Ron -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Dana Mitchell Sent: Tuesday, August 26, 2014 5:54 AM To: [email protected] Subject: [Bulk] Re: [IBM-MAIN] [Bulk] Re: [IBM-MAIN] General question on moving DFHSM work from mix TAPE/DASD to More DASD On Tue, 26 Aug 2014 00:18:21 -0700, Ron Hawkins <[email protected]> wrote: >A three tier strategy using HDD or SSD for Tier 1, Nearline SAS for >ML2, and virtualized Brand-X midrange storage for Tier 3 presents a new >paradigm for archiving inactive and dormant data sets, including >back-ups, that I believe over time can displace DFSMShsm altogether. > How does that present the location of the data to z/OS? You just have one giant pool of VOLSERs, and once a dataset is written to a DASD volser, it's z/OS percived location never changes, but the hardware is busy moving virtual tracks around amongst T1, T2 and T3 as it sees fit? That's an intriguing idea, I'd be all for getting rid of HSM. What could you use for managing retention and retrieval of application backups and archives? Dana ---------------------------------------------------------------------- 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
