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
When backup was taken on Tuesday there were 2 new generations created and the backup would have
After restore from the Tuesday backup, the DR site now shows
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.
, we restored using ADRDSSU from a backup taken with the DUMP.
Joined: 14 Mar 2007 Posts: 8686 Location: Back in jolly old England
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)
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.