- VSAM structures
- VSAM commands
- Performance tuning
- JCL Buffers
- LSR Buffers
- System Buffers
- VSAM parameters
- IAM, a VSAM alternative
- VSAM Recovery
- VSAM RLS, DFSMStvs
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. As this is unacceptable to businesses today, 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.
Any successful restore 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 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
v= 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
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.
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.
The name CICSVR is a bit misleading, as the product works independently of CICS. It can recover KSDS, ESDS and RRDS files. You use an ISPF interface to select the datasets you want to recover, then create the recovery jobs.
If the VSAM file was backed up using DFHSM, then CICSVR will use DFHSM to get the file back to the recovery point.
It then selects the CICS recovery logs, and applies them in the correct order.
Finally, CICSVR reruns any failed transaction backouts, to remove uncommitted updates.
CICSVR can recover several VSAM clusters in a single job. Information about backups is held in a CICSVR file called the recovery control data set RCDS).
RUV works in both batch and online environments. It does more than just forward recovery, it also provides backup, journal and log record management, and reporting facilities and it can backup VSAM files while they are open to CICS. It works with KSDS, ESDS, RRDS, and VRRDS VSAM files and their associated indexes and journals batch changes to VSAM files to enable forward and backout recoveries.
You can group file together into 'application groups' and request backup, restore, and recovery processes using these groups. You can recover groups of file using file masks, or you can simply supply the fully qualified file name.
RUV records backups and journals in its register. It automatically registers its own backups, and allows external backups to be registered too. It then automatically builds recovery JCL using its register.
The RUV backups facility can handle files that are open to CICS for updates, with integrity. It can also use hardware snapshot utilities to perform 'instant' backups, and can also perform 'instant' restores from these snapshots.
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 that the uncatalogued components are held on
DEFINE CLUSTER -
DATA (NAME(PIN.MVSOLZAX.ZMG.DATA) VOLUMES(DV000E) ) -
NDEX (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) -
DELETE PIN.MVSOLZAX.ZMG.INDEX -
VVR FILE(DD2) -
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 -