DFSMStvs supports a set of forward recovery log streams.
These log streams are separate from the DFSMStvs undo log streams. Each installation
determines the number of forward recovery log streams.
DFSMStvs logs the forward recovery records to system-logger
log streams. These log streams are shared across DFSMStvs instances and provide
sysplex-wide log streams that you can use as input to forward recovery products,
for example, CICSVR.
For data sets with LOG(ALL) specified, DFSMStvs backout processing creates
the forward recovery log records. These records, due to their more recent
time stamps, supersede the corresponding forward recovery records generated
during earlier processing of the unit of recovery. The log records are in
the order in which the changes are made. When forward recovery is needed,
the forward recovery product reads through the records and actually makes
the change, and then find the compensating record and undoes the change. The
records do not supersede one another; both changes are applied.
You can use one forward recovery log stream for multiple data
sets, so you do not need to define a log stream for each forward recoverable
data set. Consider the following criteria before you decide to share a forward
recovery log stream:
- Your installation's ability to balance transaction performance
- Rapid recovery
- The work involved in managing a large number of log streams
The system logger can store all the forward recovery log records from
multiple DFSMStvs instances in a shared forward recovery log.
Here are some guidelines for defining forward recovery logs:
- Have all the data sets used by one transaction share the
same log stream to reduce the number of log streams that are written to at
a sync point.
- Share a forward recovery log stream between data sets if these conditions
are true:
- The data sets have similar security requirements.
- The data sets have similar backup frequencies.
- The data sets are likely to need restoring in their entirety at the same
time.
- Choose log stream names that relate to the data sets. For example, PAYROLL.data_sets
could be mapped to a forward recovery log named PAYROLL.FWDRECOV.PAYLOG.
- Do not mix high-update frequency data sets with low-update frequency data
sets. This causes a disproportionate amount of unwanted log data to be read
during recovery of low-update frequency data sets.
- Do not put all high-update frequency data sets on a single log stream
because you could exceed the throughput capacity of the stream.
- Do not define too many data sets to a single log stream. Doing so could
cause frequent structure-full events when the log stream cannot keep up with
data flow.
- Delete redundant data from log streams periodically so that the log streams
do not become excessively large. Typically, for a forward recovery log, the
amount of old data that is deleted is related to the frequency that data is
backed up. For example, you might keep the four most recent generations of
backup. When you delete a redundant backup generation, you should also delete
the corresponding redundant forward recovery log records. These are the records
older than the redundant backup because they are no longer needed for forward
recovery. The log of logs provides information to forward recovery programs
such as CICSVR.
You can have a separate forward recovery log by data set, rather
than by job. A separate forward recovery log by data set has these benefits:
- Recovery can be more straightforward with a one-to-one relationship between
logs and the data sets to be recovered.
- Shared logs are related to multiple jobs and units of work using the same
data set.
The log of logs provides a summary of which recoverable VSAM data sets
DFSMStvs has used, when the data sets were used, and to which log stream the
forward recovery log records were written. If you have a forward recovery
product that can utilize the log of logs, ensure that all DFSMStvs instances
sharing the recoverable data sets write to the same log of logs. Do not share
the log of logs between test and production DFSMStvs instances. Sharing the
log of logs could compromise the contents of production data sets during a
restore operation.
Figure 1 gives an example of defining forward
recovery log streams for DFSMStvs and CICS®.
Figure 1. Sample definitions of forward recovery logs//DELFR JOB ,'DEFINE FR LOGS',
// CLASS=A,MSGCLASS=H,NOTIFY=SYSUSER
//*********************************************************
//*THIS JOB DELETES AND REDEFINES THE LOG STREAMS USED
//*FOR FORWARD RECOVERY BY THE TVS AND CICS WORKLOADS.
//*Note that this defines the structures and logs to the logger
//*policy. To use the structures, you must have defined them
//*to the CFRM policy.
//*********************************************************
//LOGDEF EXEC PGM=IXCMIAPU
//SYSPRINT DD SYSOUT=A,DCB=RECFM=FBA
//SYSIN DD *
DATA TYPE(LOGR) REPORT(YES)
DELETE LOGSTREAM NAME(TVSRCVY.GROUP1E)
DELETE LOGSTREAM NAME(TVSRCVY.GROUP2E)
DELETE LOGSTREAM NAME(TVSRCVY.GROUP1F)
DELETE LOGSTREAM NAME(TVSRCVY.GROUP2F)
DELETE LOGSTREAM NAME(TVSRCVY.GROUP3F)
DEFINE LOGSTREAM NAME(TVSRCVY.GROUP1E)
STRUCTNAME(LOG_IGWFR) LS_SIZE(4720)
AUTODELETE(YES) RETPD(2)
LS_DATACLAS(LOGRDC)
LS_STORCLAS(S1P02S01)
DIAG(YES)
STG_DUPLEX(YES)
DUPLEXMODE(COND)
STG_SIZE(6000)
STG_STORCLAS(S1P02S01)
STG_DATACLAS(LOGRDC)
DEFINE LOGSTREAM NAME(TVSRCVY.GROUP2E)
STRUCTNAME(LOG_IGWFR) LS_SIZE(4720)
AUTODELETE(YES) RETPD(2)
LS_DATACLAS(LOGRDC)
LS_STORCLAS(S1P02S01)
DIAG(YES)
STG_DUPLEX(YES)
DUPLEXMODE(COND)
STG_SIZE(6000)
STG_STORCLAS(S1P02S01)
STG_DATACLAS(LOGRDC)
DEFINE LOGSTREAM NAME(TVSRCVY.GROUP1F)
STRUCTNAME(LOG_IGWFR1) LS_SIZE(4720)
AUTODELETE(YES) RETPD(2)
LS_DATACLAS(LOGRDC)
LS_STORCLAS(S1P02S01)
DIAG(YES)
STG_DUPLEX(YES)
DUPLEXMODE(COND)
STG_SIZE(6000)
STG_STORCLAS(S1P02S01)
STG_DATACLAS(LOGRDC)
DEFINE LOGSTREAM NAME(TVSRCVY.GROUP2F)
STRUCTNAME(LOG_IGWFR1) LS_SIZE(4720)
AUTODELETE(YES) RETPD(2)
LS_DATACLAS(LOGRDC)
LS_STORCLAS(S1P02S01)
DIAG(YES)
STG_DUPLEX(YES)
DUPLEXMODE(COND)
STG_SIZE(6000)
STG_STORCLAS(S1P02S01)
STG_DATACLAS(LOGRDC)
/*