z/OS VSAM Recovery

VSAM files are typically used by on-line transaction based applications. VSAM files used by a DBMS can use the DBMS forward recovery process. VSAM files driven by CICS need traditional backup methods that involve bringing the systems down at some point overnight, then copying the data off to tape. If the file gets deleted or corrupted, then all transactions made since the backup are lost. This is unacceptable to businesses today, so VSAM updates are often recorded in transaction logs, so the file can be rolled forward to the point of failure. Recovery usually involves a restore from the latest backup, then a rollforward through the logs. These processes are discussed below.

Basic Recovery from backup

DFDSS recovery

Any successful depends on a good backup first. With DFDSS, it is probably best to specify the parameters SELECTMulti(first) and Sphere to get good VSAM backups. Selectmulti(first) means that if this is the first portion of a multi-volume dataset, then DFDSS will go out and find all the other portions and dump them together. An alternative is Selectmulti(any), which means that if the volume contains any portion of a multi-volume file, DFDSS will find and backup the complete file. This can be expensive if you have a lot of multi-volume files spread over lots of disks, as you will end up taking multiple backups of each file. Sphere means dump all portions of a VSAM file, including alternate indexes and paths.

If you do the backup correctly, you should be able to just do a standard dataset restore specifying the VSAM cluster name, as long as you also specify SPHERE to get all the associated AIX clusters and paths back too. If the cluster was dumped without SPHERE, then you need to restore any Alternate Indexes as seperate clusters, and build the paths with IDCAMS commands.

FDRABR recovery

FDRABR will handle single volume VSAM files easily. you simply select the file you want to restore using the base cluster name. FDRABR will then restore all parts of the file, including alternative indexes, but FDRABR will not restore paths. You need to do that yourself using IDCAMS. The command is

DEFINE PATH ( NAME(aix.cluster.name.PATH) )

Multi-volume restores are a bit harder. If you have multi-volume datasets, its your responsibility to make sure that all the volumes are dumped at the same time, so all the parts are consistent. If the backup is ok, then a restore should be as simple as

RESTORE TYPE=ABR,DYNTAPE,DSNENQ=USE

SELECT DSN=cluster.name

FDRABR should then go away, work out which volume backups it needs, dynamically mount the tapes, dynamically mount the output volumes, and restore the cluster. You need the same number of output volumes as the original file, with sufficient space on each. FDRABR restores each part of the file as a physical sequential, with a temporary volser ####Vx. Once it restores the last part, it catalogs the file up correctly as VSAM, with the correct volsers.

If the restore fails, then the 'VSAM special considerations' section of the FDR manual will assist.

VSAM Forward Recovery

If you record all updates to a VSAM file in a seperate log, and timestamp those updates, then you can use a technique called 'Forward Recovery' to get the file back to any point in time. CICS, the IBM transaction monitor, records transaction logs. If you use raw VSAM and want to recover to a point in time, you may need a third party product to provide logging facilities. The basic requirements for VSAM forward recovery are -

A Recovery Point, which is a time at which you took a full backup of all your VSAM datasets using one of the techniques above. This provides you with a backup copy of the whole file, which you should take at regular intervals, daily or possibly weekly.

A Journal, which is a chronologically ordered list of all the changes made to datasets since a Recovery Point. The Journals (or Logs) will only contain updates made to the file. You can write CICS journals to disk or tape, and write to a single file, or flip between files. Single files are easier to maintain, but will fill up quickly if there is a lot of update activity. Journal management is used to keep track of multiple files, and present them to the recovery program in the right order.

Forward recovery is a two stage process. First the dataset is backed out to the position it was in at the recovery point by restoring backup copies. Secondly all dataset changes that have been journalled since the recovery point are applied.

Fixing VSAM file components

To delete a VSAM file, you just delete the cluster entry, and all the components are deleted with it. You can either do this with an IDCAMS DELETE job, or simply type DEL against the VSAM cluster name on a 3.4 listing (this is explained in the Z/OS utility section)

If you have VSAM components without a cluster, then you can catalog them up using an IDCAMS RECATALOG command as below. You need to know the volumes the the uncatalogued components are held on

DEFINE CLUSTER -
(NAME(PIN.MVSOLZAX.ZMG) -
RECATALOG) -
DATA (NAME(PIN.MVSOLZAX.ZMG.DATA) VOLUMES(DV000E) ) - INDEX (NAME(PIN.MVSOLZAX.ZMG.INDEX) VOLUMES(DV003B) )

Alternatively you can delete the uncatalogued components using IDCAMS statements like

//DD1 DD VOL=SER=DV000E,DISP=SHR,UNIT=DISK
//DD2 DD VOL=SER=DV003B,DISP=SHR,UNIT=DISK
//SYSIN DD *
DELETE PIN.MVSOLZAX.ZMG.DATA - VVR FILE(DD1) -
CATALOG(CATALOG.ICFUSER.USER4)
DELETE PIN.MVSOLZAX.ZMG.INDEX - VVR FILE(DD2) -
CATALOG(CATALOG.ICFUSER.USER4)

The TRUENAME is a Catalog record that relates a VSAM component to its cluster. Sometimes, usually after a failed attempt to delete a VSAM file, you can be left with an orphaned truename record in the catalog. If this happens you cannot recreate the file, you will get duplicate name failures if you try. The answer is to use IDCAMS DELETE with the TRUENAME parameter as below.

DELETE PIN.MVSOLZAX.ZMG.DATA - TRUENAME