?????????In most VSE sites the backup of data is vital for the company and the backup data needs to be easily accessible in case of disaster. Find here a good way to achieve that.

Document ID : KB000054900
Last Modified Date : 14/02/2018
Show Technical Document Details

Description

Avoid the move of physical tapes when vaulting your vital backup data's to the disaster recovery site and be sure you have the right version restored.

Solution

In most VSE sites the backup of data is vital for the company and the backup data needs to be easily accessible in case of disaster.

Up to now, if data needed to be secured, many users were using the VAULTING process of CA DYNAM/T to identify which backup tapes needed to be stored offsite. This manual process of shipping tapes offsite is prone to human error. Typically backup tapes are shipped offsite only once a day or even worse once a week leaving an open window where the current data is not secured.

z/VSE together with CA DYNAM/T VSE 7.0 SP05 and above, can be used to simplify and automate the backup process by using the IBM Virtual Tape Support of z/VSE.

For the usage of VTAPE with CA DYNAM/T VSE please refer to Product Documentation Change QI88512.

To backup files on a remote server define a range of virtual tapes to the DYNAM catalog using the DYNCAT SCRPOOL command as follows:

SCRPOOL FIRSTVOL=VTxxxx LASTVOL=VTxxxx,VIRTAPE=VTAPE      - 
VTAPFILE='x:\dir\dir\VTAP.VOLSER.AWSTAPE'                 -        VTAPLOC='nnn.nnn.nnn.nnn:2386' 

FIRSTVOL and LASTVOL specify the range of virtual volsers being added to the catalog. The first 2 positions of the vtape volume serial number can be used to differentiate a virtual tape from a real tape volser.

VTAPFILE identifies the directory/file name of the vtape file on the server. The field 'VOLSER' in the name will be replaced by the volume serial number in the file name.

VTAPLOC is used to specify the IP address where the virtual tape is to be written.

When the backup is finished, a secured backup of the DYNAM catalog should also be written to a virtual tape on the remote server. By doing this it will be easy to recover from a disaster because all the important tapes are located on the remote server. To know what tape to restore after a disaster, a file containing the volume serial number of the DYNCAT BACKUP should be sent to the server where the BACKUP resides. The file should have a name that identifies the file exactly. It might also be a good idea to FTP the JCL that should be used to do the RESTORE of the DYNAM catalog to this server in addition to the volume serial of the DYNAM backup tape. This all can be done automatically using REXX programs.

Sample JCL for the backup follows :

* $$ JOB JNM=DYNCAT,CLASS=A,DISP=D 
  * $$ LST CLASS=A,DEST=(,uuuuuuuu),DISP=D <== change             
  // JOB DYNCAT uuuuuuuu <== change             
  * BACKUP OR RESTORE DYNAM CATALOG BEFORE TESTS 
  // TLBL IJSYSBK,'DYNAM.CATALOG.BKUP' 
  // EXEC DYNCAT 
  BACKUP 
  /* 
  * CREATE DATASET WITH VOLUME SERIAL NUMBER 
  // DLBL TEST,'PRINTED.LIST.OUTPUT' 
  // EXTENT SYS007,vvvvvv,1,0,sss,nnn <== change                                                
  // LIBDEF PROC,SEARCH=lib.sublib <== change             
  // EXEC REXX=REXXMSG 
  /* 
  * FTP THE DATASET WITH VOLUME SERIAL NUMBER 
  // DLBL FIL1,'PRINTED.LIST.OUTPUT' 
  // EXTENT SYS005,vvvvvv,1,0,sss,nnn <== change                                              
  // ASSGN SYS005,DISK,VOL=vvvvvv,SHR <== change                                          
  // EXEC FTPBATCH,PARM='IP=nnn.nnn.nnn.nnn' <== change             
  user <== change             
  pass <== change             
  uuuuuuuu <== change             
  pass <== change             
  CD /directory <== change             
  PUT %FIL1,SAM,V,12288 fn.ft <== change             
  QUIT 
  /*
  /&
  * $$ EOJ 

The REXX IMOD REXXMSG attached to this document should be uploaded in BINARY FIX 80