If I ever get some spare time I need to analyze our current migration
rules and do some tuning. I'm sure we are moving some things to ML1 and
back that would best be left alone.
But that said, when you add DR to the mix, movement to ML2 tape of the
"really" idle datasets with low recall rates can continue to make a lot
of sense, no matter how cheap DASD gets. Move idle data to ML2 with
duplexing with the duplex tape "vaulted" offsite, and the data is
covered for DR without having to touch it again for months. Leave the
data on a DASD volume where new allocation is possible and you're going
to need to back up the same data to tape repeatedly to be covered for
DR. The only thing I can see that would change that reality would be to
have an environment that can justify and afford mirrored remote DASD -
but unless you can also afford enough DASD to save multiple DASD farm
images you may still need some point-in-time tape backups as well, just
to handle those data loss situations caused by user or program errors
rather than by hardware or data center failure.
Ron and Jenny Hawkins wrote:
Chris,
A good argument when you are migrating between "like" disk technology and
compression of the data is the only saving. However, now that us mainframers
have access to cheaper rack & stack storage and SATA disk the economics of
migration change, and the savings may be more substantial than before.
With very cheap disk there can be savings realised on ML1 without
compression, which would also translate to a MIPS saving. With SATA running
at prices similar to tape the economics of disk=ML1 and Tape=ML2 can be
turned on its head.
IMHO it also makes a whole new ball game for TMM, where savings can be
realised with less aggressive interval migration.
There are sites out there that measure migrated data in tens of TB, and at
least one that counts silos. That's a lot of money saved out of anyone's
chequebook, but they probably have rules that are better defined than Mark
Z's experience. Avoiding long weekend "thrash" is the first design rule in
HSM migration planning.
Ron
Has anyone checked to see whether there's any practical reason (i.e.
$$$) to migrate at all? Disk is pretty cheap these days and HSM is a
notable pig in most shops, ours included.
I question the value of spending CPU cycles shoveling bits from one cold
place to another - typically in the same array. If it were mine, I'd
leave it spinning on disk until it was so old it had cobwebs on it. Then
if I cared enough about the space, I'd shove it out to a big fat tape
vault and forget about it. YMMV.
...
--
Joel C. Ewing, Fort Smith, AR [EMAIL PROTECTED]
----------------------------------------------------------------------
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
