Portal | Manuals | References | Downloads | Info | Programs | JCLs | Mainframe wiki | Quick Ref
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Profile Log in to check your private messages Log in
 
Old gds of GDG not rolledoff after ADRDSSU restore fr backup

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> IBM Tools
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    Post subject: Old gds of GDG not rolledoff after ADRDSSU restore fr backup
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: 8686
Location: Back in jolly old England

PostPosted: Mon Feb 12, 2018 1:35 pm    Post subject:
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: 5
Location: Australia

PostPosted: Tue Feb 13, 2018 8:18 am    Post subject: Reply to: Old gds of GDG not rolledoff after ADRDSSU restore fr backup
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.

https://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: 461
Location: London

PostPosted: Sun Jun 10, 2018 12:15 am    Post subject:
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    IBMMAINFRAMES.com Support Forums -> IBM Tools All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Invoking adrdssu using attchmvs harisukumaran IBM Tools 5 Tue Jun 05, 2018 3:30 am
No new posts Cannot change DATACLAS on DFSMSdss re... Alan Playford JCL & VSAM 11 Tue May 01, 2018 6:43 pm
This topic is locked: you cannot edit posts or make replies. Unavailable RECON datasets while exec... abdulrafi JCL & VSAM 10 Fri Apr 06, 2018 12:45 pm
No new posts IMS Database backup info ashek15 IMS DB/DC 14 Wed Nov 16, 2016 5:29 am
No new posts Error during restore rename archanamuthukrishnan All Other Mainframe Topics 2 Fri Oct 14, 2016 3:30 pm

Facebook
Back to Top
 
Job Vacancies | Forum Rules | Bookmarks | Subscriptions | FAQ | Polls | Contact Us