How to backup/restore a VSAM file?

[m4mainframe]

I am interested in knowing how to backup a VSAM file and how to restore it back without worrying about the existence of the VSAM cluster etc. i.e. if it exists it should overwrite it and if it do not exist, it should create it like we do it on windows for a any normal files.

Let's say the name of the VSAM file whose backup is to be taken is - USERID.TEST.VSAM - can be of any type of VSAM.
and the name of the backup file is - USERID.TEST.VSAM.BKUP

So, what I want is 2 JCL -->
1) JCL ready to be submitted to get the USERID.TEST.VSAM.BKUP created irrespective of existence of USERID.TEST.VSAM.BKUP.
2) JCL ready to be submitted to get the USERID.TEST.VSAM created back irrespective of existence of USERID.TEST.VSAM

[Robert Sample]

like we do it on windows for a any normal files.

You need to learn, since you do not yet apparently know, that z/OS is not Windows and Windows is not z/OS. Things that are simple in Windows may be impossible in z/OS and things that are easy in z/OS may be impossible in Windows.

Is your .BKUP file supposed to be sequential or another VSAM file of the same type? If sequential, are you putting it on tape or disk? If on tape, does your site allow a tape data set to be overwritten (HINT: VERY FEW SITES ALLOW TAPE DATA SETS TO BE OVERWRITTEN)? Is the backup file only to be used internally or will it be used off site as well? If VSAM of the same type, how are you determining the type for the backup copy?

Your first job can best be implemented as two steps: an IEFBR14 step that specifies USER.TEST.VSAM.BKUP with DISP=(MOD,DELETE,DELETE) and provides the full DCB for the backup file, followed by a step using the backup tool of your choice (ADRDSSU would be preferred, but IDCAMS would work).

Your second job, if implemented using ADRDSSU, would require the REPLACEUNCONDITIONAL keyword on the RESTORE command.

Considering the easy access to IBM manuals, and the generally great variety of jobs previously written at most sites, I don't typically provide code (or JCL) except to make (or rebut) a point. If you write the JCL, and it doesn't work, I can point out where you went wrong -- but I"m not going to just give away my work product for free.

[LearnMainframe]

For first JCL you ask for try this, but have you made some JCL yourself too?

Code: Select all

//STEP01   EXEC PGM=IEFBR14                 
//SYSUT1   DD  DSN=USER.TEST.VSAM.BKUP,
//             DISP=(MOD,CATLG,DELETE),     
//             UNIT=SYSDA,RECFM=FB,LRECL=80,
//             SPACE=(CYL,(1,1),RLSE)       
//*
//STEP02    EXEC PGM=IDCAMS 
//SYSPRINT DD SYSOUT=* 
//DD1      DD DSN=USER.TEST.VSAM.BKUP,UNIT=TAPE, 
//            DISP=OLD,DCB=(appropriate parameters) 
//DD2      DD DSN=USERID.TEST.VSAM,DISP=OLD 
//SYSIN DD * 
  REPRO - 
  INFILE(DD2) - 
  OUTFILE(DD1) 
/*

[Anuj Dhawan]

There are some assumption need to be made before one provides you a solution - for example, can the VSAM have alternate-index? If yes, you must IMPORT and EXPORT both the alternate index and the VSAM data-set.

To get you going - following Job creates a tape backup named VSAM.BACKUP.ALTNDX of the alternate index named VSAM.ALTNDX associated with the VSAM data-set. Both backups are kept on the same tape volume. The alternate index must be backed up first.

Code: Select all

//STEP1    EXEC PGM=IDCAMS 
//SYSPRINT DD SYSOUT=* 
//BACKUP   DD DSN=USER.VSAM.BACKUP.ALTNDX, 
//            DISP=(NEW,CATLG,DELETE), 
//            UNIT=TAPE,VOL=(,RETAIN) 
//SYSIN DD * 
  EXPORT VSAM.ALTNDX - 
  OUTFILE(BACKUP) 
/* 
//STEP2    EXEC PGM=IDCAMS 
//SYSPRINT DD SYSOUT=* 
//BACKUP   DD DSN=USER.TEST.VSAM.BKUP, 
//            DISP=(,CATLG,DELETE), 
//            UNIT=TAPE,LABEL=(2,SL),VOL=(,,REF=*.STEP1.BACKUP) 
//SYSIN DD * 
  EXPORT USERID.TEST.VSAM - 
  OUTFILE(RECEIVE) 
/*

And you'd need IEFBR14 steps to define the backup files as Robert said and LearnMainframe shows.

[Robert Sample]

ADRDSSU (also known as DF/DSS) has the advantage that by specifying SPHERE as one of the options on the DUMP statement, all associated alternate indexes will also be included. There are some cautions with ADRDSSU, such as the dump block size being more than 32767 bytes and the requirement that dumps be copied using DF/DSS. However, as long as a logical dump was taken DF/DSS allows restores to be done to the same name, or different names, as needed (note that if the new name does not have the same number of qualifiers the restore must specify each individual data set to be renamed).

[Anuj Dhawan]

Thanks Robert. I missed your mention about ADRDSSU in previous reply. ADRDSSU is a better choice for this...

[Robert Sample]

ADRDSSU can back up data sets open by other programs (such as CICS), although in such cases there is the chance of getting inconsistent data backed up. ADRDSSU works with SMS, so there are class options available, and ADRDSSU can back up many files with a fairly short command stream. The only drawback to backing up many files is that it creates the list of files to be backed up and the volumes they are on, and if (for example) batch production is running while ADRDSSU is doing the back ups, data sets may have changed volumes and hence miss being backed up by ADRDSSU.