I'm of the opposite opinion. Virtual tapes should be used for most large sequential datasets. Only exceptions are datasets that are required to be read by multiple subsequent jobs at the same time. No B37 ABENDs ever, lower cost and much more easily recovered if something gets "accidently" deleted.
On Tue, 7 Jul 2020 at 13:29, Timothy Sipples <sipp...@sg.ibm.com> wrote: > Radoslaw Skorupka wrote: > >I forgot something obvious for me: NEVER USE TAPES FOR APPLICATION > >DATA. No jobs should write or read tapes. > >Nothing except backup and restore and (optionally) ML2. Managed by > >HSM or FDR. Some excepions for archive copies are worth to consider. > > I take your point, but "NEVER" is too strong. And you're acknowledging > there might be some exceptions, so let's dig into them a bit. > > One notable exception that I'm increasingly encountering is in the digital > asset industry. There are occasions when they'd like to have certain > digital assets in an offline state, for example in technically and > operationally assured systems, encrypted on WORM tape cartridges > physically removed from tape libraries. In some cases that sort of > approach is what the asset owners and their insurers require. Another > potential exception involves certain content management systems, although > it depends on how they're designed. > > As another example, IBM SAFR runs really don't mind source data from tape > and/or virtual tape. As long as the data streams fast enough for whatever > you're trying to do with SAFR, that's perfectly fine. > > I suppose you could drive even these edge cases through DFSMShsm handling > (and manual tape loading procedures in the first example), but then you'd > need above average cooperation with application developers and owners. The > "my application knows best" philosophy is powerful, for better or worse. > You just try to do the best you can, and if there's an exceptional edge > case and consensus agreement that it ought to be handled differently (even > if you disagree), OK, so it goes. > > - - - - - - - - - - > Timothy Sipples > I.T. Architect Executive > Digital Asset & Other Industry Solutions > IBM Z & LinuxONE > - - - - - - - - - - > E-Mail: sipp...@sg.ibm.com > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
