Thanks everyone. Much appreciated. With TMM, of course it goes to expensive z/os disk, but we do have the option of tiering within the array, such as using 1tb drives Raid6 and then hsm them to replicated vts later. On Nov 23, 2010 4:39 AM, "Michael W. Moss" <[email protected]> wrote: > Maybe phrasing your question differently would be what are the > advantages and disadvantages of physical tape data versus a tape-on- > disk approach? > > TMM is a methodology, which temporarily stages tape data on Level 0 > disk and then the TMM pool is managed by DFSMShsm or equivalent to > consolidate this data on physical tape. The resulting physical tapes > will then have data sets with varying expiration criteria and so will > require recycling periodically and from a DR/BC viewpoint will require > duplicating, as and if required. > > IBM Virtual Tape for Mainframe (VTFM) essentially is a virtual tape > solution, emulating 3480/3490/3590 drives and allocating tape data to > physical z/OS DASD. Of course, there are many other z/OS virtual tape > solutions, with a tape-on-disk type concept, CA VTape being a > software example, requiring physical tapes for data destaging, with > Bus-Tech MDL/EMC DLm, Luminex, Universal Software, Intercom being > appliance solutions that allocate tape data to FC/NAS disk arrays, > without subsequent data destaging to physical tape, and of course > IBM TS7700 (VTS), Oracle/StorageTek VSM and FSC CentricStor being > solutions that combine a disk cache and physical tape. > > So thinking of Sherlock Holmes “when you have eliminated the > impossible, whatever remains, however improbable, must be the > truth”, maybe you could review all of the tape-on-disk options, which > include TMM? > > Some advantages of those solutions, and so for the avoidance of > doubt, Bus-Tech MDL/EMC DLm, Luminex, Universal Software, Intercom, > et al, is that the resulting ML2 type data, can be easily recycled, as > the “tape” data is on cost-efficient FC/SAN disk, and thus easier data > replication for BC/DR is also possible. Equally, ML1 type operations > could also be eliminated, with all of the resource considerations (E.g. > CPU, z/OS class DASD) associated with that process. Thus for the > avoidance of doubt, avoid ML1 disk costs and zSeries CPU cycles, by > eliminating ML1 from the storage hierarchy and go direct to ML2, where > compression is performed outboard of the Mainframe and tape data > allocated on less expensive FC/IP disk arrays, potentially with the > benefits of deduplication. > > All that said, maybe even TMM can co-exist with such a tape-on-disk > methodology. > > As with any IT solution, identify your business requirements first and > then research what products best fit your business requirements with > the best ROI and TCO attributes. So maybe VTFM isn’t for you and > maybe TMM can be approached from a different viewpoint for you by > utilizing other virtual tape technologies. > > > On Mon, 22 Nov 2010 11:30:08 -0500, techie well wisher > <[email protected]> wrote: > >>IBM has VTFM (which is diligent/copycross, etc). Why do we need this > product >>or use this product while we can directly intercept and direct >>allocations to a particular storage group (such TMMGROUP) with disk > volumes, >>let's say a dedicated set aside pool from a storage device? With > extended >>dataclas attribute, the datasets in this group could be really huge > (several >>gigabytes). To me, this product adds unnecessary complexity. With > this, we >>don't need PAT (parallel tape access), because all the datasets in this >>group are disk datasets, accessible by multiple address spaces/jobs. > Pleaset >>let me know your thoughts or am I missing something here? >> >>TW >
---------------------------------------------------------------------- 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
