View previous topic :: View next topic
|
Author |
Message |
Wallace Lee
New User
Joined: 08 Feb 2018 Posts: 1 Location: Canada
|
|
|
|
This is what we did and found in a disaster recovery test.
1) DASD group took a full backup of all packs on Sunday (not sure what utility was used)
2) Our application used ADRDSSU on Wednesday to take backup of all ATPC datasets, with commands below:
DUMP OUTDDNAME(TAPE1) DATASET(INCLUDE(ATPC.**)) -
ALLDATA(*) ALLEXCP CANCELERROR WAIT(0,0) OPTIMIZE(1) SHR
3) At the DR site, DASD group first restored from the all packs backup taken on Sunday
4) We then ran ADRDSSU to restore from the Tuesday backup
RESTORE INDDNAME(TAPE1) OUTDDNAME(DASD1) -
DATASET(INCLUDE(ATPC.**)) REPLACE CATALOG TGTGDS(ACTIVE)
5) We noticed some issue with the GDG datasets. Here's an illustration of the problem with a GDG defined with a limit of 3 generations.
After restore from the full packs backup, we saw
ATPC.ATPC40.GDG1
ATPC.ATPC40.GDG1.G0002V00
ATPC.ATPC40.GDG1.G0003V00
ATPC.ATPC40.GDG1.G0004V00
When backup was taken on Tuesday there were 2 new generations created and the backup would have
ATPC.ATPC40.GDG1
ATPC.ATPC40.GDG1.G0004V00
ATPC.ATPC40.GDG1.G0005V00
ATPC.ATPC40.GDG1.G0006V00
After restore from the Tuesday backup, the DR site now shows
ATPC.ATPC40.GDG1
ATPC.ATPC40.GDG1.G0002V00
ATPC.ATPC40.GDG1.G0003V00
ATPC.ATPC40.GDG1.G0004V00
ATPC.ATPC40.GDG1.G0005V00
ATPC.ATPC40.GDG1.G0006V00
G0002 and G003 remain on the catalog but apparently not on the base, as reference BY ATPC.ATPC40.GDG1(-4) fails. Post recovery if a test job creates G0007, older generations still show on the catalog but are probably rolled off the base. Why did older generations fail to disappear post recovery? What did we do wrong in the backup and recovery processes?
I tried the ADRDSSU with DEFERRED, ROLLEDOFF, SOURCE option for the TGTGDS command and none worked either. The behaviour was the same whether the GDG was defined with SCRATCH or NOSCRATCH option.
Thank you in advance for any expert's help.
Wallace
, we restored using ADRDSSU from a backup taken with the DUMP. |
|
Back to top |
|
 |
expat
Global Moderator

Joined: 14 Mar 2007 Posts: 8796 Location: Welsh Wales
|
|
|
|
I recall the same problem back in the late 90's
and I'm buggered if I can remember what I did to fix it
I think for some reason that the recovered GDGs were restored as DEFERRED, so I used IDCAMS to delete any unwanted, and then to reset any that remained to ACTIVE (or whatever - no mainframe access in my current job) |
|
Back to top |
|
 |
hankoerlemans
New User
Joined: 25 Jan 2018 Posts: 64 Location: Australia
|
|
Back to top |
|
 |
Pete Wilson
Active Member
Joined: 31 Dec 2009 Posts: 592 Location: London
|
|
|
|
You need to do a LISTCAT against the ones you think should have been deleted. They'll probably show a status of DEFERRED or ROLLEDOFF. Maybe the full volume restore didn't have TGTGDS(SRC) or TGTGDS(ACTIVE) specified and defaulted to DEFERRED. Or possibly those datasets were already in that state when the full volume backups were done. If a batch job fails while creating a GDS it leaves it in DEFERRED status, and will 'reuse' that generation next time you write to the base with (+1), and will roll it in if the jobs works. (if you have CA11 that would normally delete them on the restart, then create it new)
If you don't want those generation they can just be deleted
You might avoid picking up any deferred or rolledoff generations in your backup by coding (*) at the end of the name mask which implies taking all generations and should not take datasets not associated with the base.
DUMP INDDNAME(TAPE1) OUTDDNAME(DASD1) -
DATASET(INCLUDE(ATPC.**(*) )) |
|
Back to top |
|
 |
|