Be very careful if you think extended retention or anything a tape management system can do in delaying return to scratch will help you.
My belief is that the problem is totally with how these virtual tape systems handle scratching of volumes. They accept a list of volsers as input, usually no validation of the list - whether it is actually the correct, current list, and immediately (as Tom said) marks volumes scratch and reclaims the space. You should be looking for a 'grace' period during which policy prevents loss of data on newly scratched tapes - giving time to check what happened. ALso look for some validation that the input list is correct and the latest one. That it matches data from the tape management system. Better still request an interface such that the tape management system can drive the scratch from its own data. With IBM VTS/VTL and rmm you get the above options. The rmm extract, which I know some systems use to drive scratch, contains a header record with the data and time, and each volume record contains the data and time it was set to scratch. Plenty of ways to perform validation. Mike Wood RMM Development On Tue, 12 Jan 2010 07:42:40 -0700, Lester, Bob <bles...@oppenheimerfunds.com> wrote: >----Original Message----- snip > >> Can't you use CA-1's extended retention options for this? >> See Ch 1.6.3.5 Retention Options in the System Programmers Guide. > >> Kees. > >Hi Kees, > > I hadn't thought of that approach. Thanks for the tip! > >Bob Lester > >---------------------------------------------------------------------------- ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
