> This methodology can give you a scanable tape but it does increase your > i/o load and elapsed time quite a bit.
It's manageable if you can put the "scratch" disk out of the line of processing for production work (ie, different string or controller). > If you have enough spare DASD, > you could do all of your production backups to DASD during your backup > window and then move the CMS files to tape after your backup window. But > it requires quite a bit of DASD, I could only get 2 3390-m9 volumes to a > 3390-m9 storage volume, so I needed 16 spare DASD for the then 32 > production DASD. Using CMS files as interim storage makes it possible to also use SFS for the scratch space. While that may not solve the problem of how much you can fit on a limited amount of real DASD, it does solve the problem of having to fit it onto a single physical volume at a time. Now that I think of it, it also makes the disk image files eligible for DFSMS management, which (much as I regret the dependency on TSM/VM) makes it fairly easy to get the volumes offline easily and recall them easily, and there is a clear and well documented recovery methodology for TSM/VM and the associated SFS pool. That, plus a 1 pack recovery system, and you're done. Hmm. I'll have to go try that. > Having a standard VOL1 label on the tape is easy to do in your > controlling exec, either by forward spacing past it if it exists when > you get the tape mounted or you can write one yourself. I read the label > and then rewrite it adding the userid of the server my backup is running > in. > The DDR tape data includes information about the volume dumped. It > should not be too hard to write an exec to read a tape and report on the > label and ddr contents. Eventually that processing could be added to the > TAPEMAP program which already knows about TAPE and VMFPLC2 data content. Yes, you can, but the method I outlined doesn't require such deep magic -- all documented interfaces that IBM has to maintain...8-).
