Many CICS® applications depend on their data sets being open for update over a long period of time. Normally, you cannot take a backup of the data set while the data set is open. Thus, if a failure occurs that requires forward recovery, all updates that have been made to the data set since it was opened must be recovered. This means that you must keep all forward recovery logs that have been produced since the data set was opened. A heavily used data set that has been open for update for several days or weeks may need much forward recovery.
The BWO facility, together with other system facilities and products, allows you to take a backup copy of a VSAM data set while it remains open for update. Then, only the updates that have been made since the last backup copy was taken need to be recovered. This could considerably reduce the amount of forward recovery that is needed.
Concurrent copy improves BWO processing by eliminating the invalidation of a BWO dump because of updates to the data set. The following is a comparison of various kinds of dumps that you can request:
To use concurrent copy, specify the CONCURRENT keyword when you use DFSMShsm to dump BWO data sets.
The BWO function allows backups to be taken by DFSMSdss when applications are running in continuous operation while the data set is open for update with full data integrity of copied data. (Continuous operation is typically 24 hours-a-day for five to seven days a week.) This is feasible only for CICS VSAM file control data sets for which CICS creates forward-recovery logs. Long-running transactions, automated teller machines, and continuously available applications require the database to be up and running when the backup is being taken.
The concurrent copy function used along with BWO by DFSMSdss allows backups to be taken with integrity even when control-area and control-interval splits and data set additions (new extents or add-to-end) are occurring for VSAM key sequenced data sets.
[[ Contents Previous Page | Next Page Index ]]