🚀 go-pugleaf

Does anyone use VM/Archive to store production data?  If so, how do you
handle getting copies of tapes off site so that you can recover this
data in the event of a disaster where you tape library goes up in
smoke?

We've been talking to Systems Center about this problem.  They keep
suggesting that we close out a tape set every day, mark the twin as
missing, and take it off site.  Every week we should then run merge
purge to combine the weeks worth of data on a primary and a twin,
mark this twin as missing, send it off site, bring back in the
daily "missing twins", reinitialize them and add them back to the
VM/Archive tape pool.  Do this process every week then use the
same idea to combine weekly into monthly, monthly into quarterly,
and quarterly into annuals.

While the logic makes sense, implementing this idea would be a nightmare.
This process would need to interface with the tape management system and
the off site vaulting system used by the TMS.  Keeping track of all off
these tapes, when they had good on site data, when they have good
off site data, when they are off site, when they have been physically
returned on site and can be used again.  The whole process gets pretty
ugly.

We had developed a process where every night a service machine does
a VMARCH VOLUME QUERY and looks at the last use date of every VM/Archive
tape.  It compared this last used date to the creation date of a
tape that was basically a MOVEFILE copy of the VM/Archive tape.  If
the VM/Archive tape had been used more recently then our copy we'd mount
the VM/Archive tape, call for a scratch with a dataset name showing
this was an off site copy of the original VM/Archive tape, and use
MOVEFILE to move a copy of the VM/Archive data to our off site scratch.
We use cycle control on these off site tapes so older copies go scratch
and simply return to the scratch pool.

It seems to me that our solution is much simpler than what Systems Center
is suggesting.  They keep warning us that our solution may not work and
the jazzy weekly/monthly/quarterly/annual etc. merge purge process is
the only valid way to do this.

What are you doing?  I'm afraid that many shops are just willing to
let their VM/Archive data go up in flames because there is no
reasonable solution.

We've been complaining about this to Systems Center for years and they
don't seem to be responding to our concerns.  They have some ideas that
might make things better in the next release but I'm afraid that their
developers are too removed from reality and don't really understand
the scope of this problem or acceptable ways to address it.  I sure am
glad that IBM's DF/SMS has announced support for migration to ML1 &
ML2.  I thinking about dumping VM/Archive, telling users to stop
archiving data and let DF/SMS automatically archive old data to ML2.

Any comments?

Martin J. Doyle
VM Systems Programming Contractor
Rohm and Haas Company
Philadelphia,  Pennsylvania
MBDMD@ROHVM1
(215) 592-6865 (Day)
(215) 752-2296 (Evening)