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: 8646 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)