IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Old gds of GDG not rolledoff after ADRDSSU restore fr backup


IBM Mainframe Forums -> IBM Tools
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Wallace Lee

New User


Joined: 08 Feb 2018
Posts: 1
Location: Canada

PostPosted: Fri Feb 09, 2018 9:34 pm
Reply with quote

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
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8794
Location: Welsh Wales

PostPosted: Mon Feb 12, 2018 1:35 pm
Reply with quote

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 icon_biggrin.gif

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
View user's profile Send private message
hankoerlemans

New User


Joined: 25 Jan 2018
Posts: 30
Location: Australia

PostPosted: Tue Feb 13, 2018 8:18 am
Reply with quote

I don't think ADRDSSU is as clever as you want.

If it suits your requirements try cleaning/clearing the GDG first and then run your restores.

www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.idai200/dgt3i228.htm
Back to top
View user's profile Send private message
Pete Wilson

Active User


Joined: 31 Dec 2009
Posts: 490
Location: London

PostPosted: Sun Jun 10, 2018 12:15 am
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> IBM Tools

 


Similar Topics
Topic Forum Replies
No new posts adrdssu for copy all data JCL & VSAM 5
No new posts adrdssu tool to dump a files from a PDS JCL & VSAM 5
No new posts ADRDSSU BY(REFDT... not selecting cor... IBM Tools 3
No new posts Backup issues after upgrade to zOS 2.2 All Other Mainframe Topics 0
No new posts Single step to take backup of multipl... JCL & VSAM 1
Search our Forums:

Back to Top