What/where does DFSMS check for a dataset backup prior to migrating a
dataset?
I thought that DFSMS looked in the BCDS to verify that it had a good
backup of the dataset prior to migrating the dataset to tape. However
that must not be the case, we use FDR for backup and HSM for migration
here without running HSM backups, and datasets migrate. If FDR backup
hasn't run on a dataset it won't migrate, and the error is there is no
valid backup.
Once FDR backs up the dataset HSM is able to migrate the dataset, what
is HSM looking at to validate it has a good backup prior to migration?
I was not aware that in a mixed ABR/HSM shop, that HSM would not migrate
a dataset unless FDR has backed it up. Perhaps John is right and HSM
is just checking the UPDATE flag (DS1DSCHA) since ABR turns it off on
every backup.
What message do you get from HSM when it decides it needs a backup?
This relates back to an earlier post where we have an issue with
migrated datasets not having a valid backup because the retention on
the FDR backup jobs is 60 days, and datasets are migrated much longer
than 60 days. We have users who occasionally recall a dataset that
has been migrated many months (usually smp zones), then do some work,
screw up the zone and want it recovered from a backup all in the same
day. Since the backups expire after 60 days, we have to do some HSM
manipulation to get the data back from the migration tape. I really
need a way to make sure that the last backup in FDR never expires as
long as the dataset is cataloged on the system. I haven't found that
option in FDR. I looked at FDR Archive, but I don't see a similar
option that makes sure I have a valid backup copy as long as the
dataset is archived (MIGRAT1).
ABR manages backups on a voluime-level, not a dataset-level, so there is
no way to keep backups of individual datasets beyond the volume-level
expiration.
Perhaps you can teach those users how to do a FDRDSF backup of the
datasets before they mess with them.
Or I need to let HSM do backups of the datasets and keep one version
(to guarantee I always have a valid backup for the migrated datasets),
but to do this I still need to figure out a way to keep HSM from
reseting the changed bit so it doesn't impact our FDR backups.
Or you could switch to ABR archive instead of HSM migration. Its a
similar function, but much more efficient.
--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.com
----------------------------------------------------------------------
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
