To Recover a deleted file from MVS Backup

In Mainframes, MVS takes backup of files/datasets, every time they are
changed. Also it keeps backup of these changed versions at any point of
time. So, at any point of time we can recover deleted datasets as well
as its previous versions.

To find out how many versions of a dataset are available in backup,
enter the following command in TSO (Start 6) panel.

HLIST BCDS DSN ('Dataset Name')

or type the following in the command line

TSO HLIST BCDS DSN ('Dataset Name')

This will give the list of backups. Also, every backup has a backup
date and a GEN (Generation) no. associated with it.

For example, Assume PDS ' X' is last changed on 27/12/05 after which
MVS has taken backup of all the files/datasets. If PDS 'X' has to be
recovered without change on 27/12/05, then from the backup list we need
to get the
GEN( generation) No. for the backup date which is less than (27/12/05).

Let us assume the generation to be GEN (005).

So to recover that File or PDS, enter the following command in TSO
(Start 6) panel.

HRECOVER 'Original Dataset Name' GEN(005) NEWNAME.

or type the following in the command line

TSO HRECOVER 'Original Dataset Name' GEN(005) NEWNAME.

MVS will prompt for a new dataset name. Enter the new dataset name and
MVS will recover that version with the new name.

Note:

In case a deleted dataset needs to be recovered, enter the following
command in TSO (Start 6) panel.

HRECOVER 'Deleted dataset Name'

or type the following in the command line

TSO HRECOVER 'Deleted Dataset Name'

If MVS has that backup it will recover that with same name, i.e. the
latest version.

http://mftips.blogspot.com/2005/12/...e-from-mvs.html

Thanks,
MFTips
http://mftips.blogspot.com/

This may leave many with a dangerously optimistic misconception about
how much backup activity is done for you automatically on MVS and how
omniscient MVS is about application backup requirements.

The backups to which you refer are backups that are taken by the product
DFSMShsm, an optional product of z/OS which might not be active in all
installations.  HSM is highly customizable and also tied to System
Managed Storage (SMS) definitions, which are customized and unique to a
specific MVS installation.  The installation would have to define an SMS
Management Class with the autobackup attribute, and a dataset would have
to be associated (implicitly or explicitly) with such a management class
in order to be eligible for autobackup.

Autobackup is scheduled for a specific, installation-chosen, time period
during the 24-hour day and autobackup of a specific dataset will be done
at most once a day during that time period.  The installation can also
choose how many backups will be retained for that management class and
whether a minimum number of days must have elapsed from a prior backup.
If a dataset undergoes multiple changes before it becomes eligible for
autobackup again, only the last state of the dataset will be saved in an
autobackup.  Also, if the dataset can possibly be changed during the
daily autobackup process (which may run for several hours), then you
can't even predict in advance whether the backup up version of that
dataset will be taken before or after it changes.

Bottom line, you have to know and understand the conventions that are in
place at your specific MVS installation relating to autobackup
eligibility and scheduling.  If this means you have an application that
isn't adequately protected for recovery or re-run, it is the application
implementer's responsibility to create required backups at the required
times and with the required retention cycle.  MVS has no way to guess
what the requirements might be for an arbitrary application.


mftips@gmail.com wrote:
> In Mainframes, MVS takes backup of files/datasets, every time they are
> changed. Also it keeps backup of these changed versions at any point of
> time. So, at any point of time we can recover deleted datasets as well
> as its previous versions.
...