Mike, I think that is only true for Iceberg, RVA and SVA. For HDS the VTOC is seen as your data, secure from the storage controllers operating system and the VTOC cannot be opened.
EMC, IBM and HDS thin provisioning methods allocate in pages (HDS parlance), so if you write one block on one track the whole page is allocated. For HDS the page is 672 tracks (approx 38MB) striped across the HDD/SSD in one Parity Group. For the IBM and HDS implementations, RAID Rank Striping and Hitachi Dynamic Provisioning, the wide striping that comes with this method is probably more attractive than thin provisioning with over-commitment. It has all the load-leveling advantages of RAID-0 while maintaining RAID-6 or RAID-5 protection. In the HDS case you can achieve thin provisioning by adding real Array Groups to the pool, creating more virtual volumes within the pool, and then adding them to the Storage Group. I'm not sure about the IBM or EMC implementation - perhaps someone can enlighten. Those that have embraced volume pooling automation like DFSMS, SAMS-Vantage, or even ACC will start to use the new capacity on the new virtual volumes immediately and without disruption. You can also use DVE, or the old Iceberg/RVA methodology of over-commitment and empty placeholder datasets (everything old is new again). Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of > Mike Schwab > Sent: Tuesday, February 07, 2012 11:45 AM > To: [email protected] > Subject: Re: [IBM-MAIN] Why can't the track format be changed? (was: Physical > record size query) > > Behind the scenes, some controllers only store the active amount of data for a > track, and monitor the VTOC for datasets being deleted. > This is called Thin Provisioning and allows a small amount of overcommitting. > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
