-- snip -- > VSM (and VTS) offer simple, application independent duplication for > disaster recovery purposes. When you change jobs from using virtual tapes > to real tapes you have to look at how you're going to duplicate the tapes. > It's one reason to try to keep all your tapes virtual. [...] It's one of the reasons to use HSM or FDR to make duplex copies. It costs no more CPU cycles, it fills up the tapes, it utilizes more channels (it's not a problem IMHO). If you want to write to tape directly... well... WHY do you want it? -- snip--
With most installations it's purely historical. The big data sets went directly to tape, the smaller ones went onto DASD and were then processed by HSM (or similar). With DASD prices now cheaper and still dropping, I agree with you that there shouldn't be any need to write directly to tape. Why VSM/VTS and not HSM. Well, one reason is that handling duplicates in HSM requires manual intervention. When a primary tape goes bad, you need to activate the alternate and then ensure that you produce another duplicate of this tape. All quite simple, but still manual. When a virtual tape is bad (due to a bad real physical tape), it's all handled under the covers as far as HSM is concerned. No need to screw around with primary and alternate. You do need to invest more in the size of your VSM/VTS and maybe that is reason enough not to do this. Also, implementing high availability is a lot easier when the duplexing is application independant. -- snip -- BTW: The biggest VSM/VTS advantage I in my opinion is the number of drives. It's important in multi-LPAR installation. -- snip -- That's true, but it is also important to size your VSM/VTS properly to ensure that residency time is long enough for your virtual tapes and that the tapes get migrated to the backend in a timely matter. John ---------------------------------------------------------------------- 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
