VSAM data sets defined as recoverable files must have associated
forward recovery logs. In the event of physical failure or corruption,
restore the most recent backup, and use a forward recovery utility
such as CICSVR to re-apply updates.
To recover from a DASD failure, first restore the most recent backup
to a new data set. Then use a forward recovery utility, such as CICS® VSAM
Recovery (CICSVR), to apply all the updates that were written to a
forward recovery log stream after the backup date.
Note:
Define a data set as recoverable if you want forward
recovery logging. Neither CICS nor VSAM provides any support
for forward recovery logging for a nonrecoverable data set.
You specify recovery attributes, including forward recovery, in
either the integrated catalog facility (ICF) catalog (if you are using
DFSMS 1.3 or later), or in the CICS file
resource definition. See Defining files as recoverable resources for details.
If CICS fails to connect to a general log stream because
it has not been defined, CICS attempts to have it created dynamically.
To create a log stream dynamically, CICS must
specify to the MVS™ system logger all the log stream attributes
needed for the new log stream. To determine these otherwise unknown
attributes, CICS requests the MVS system
logger to create the log stream using attributes of an existing model
log stream definition. If you decide to allow CICS to
create log streams dynamically, you are responsible for creating the
required model log stream definitions to ensure that dynamic creation
succeeds.
It is generally worthwhile setting up model log streams only if:
- Each model log stream will be used to create several log streams
- Each log stream created using a model log stream has similar characteristics
consistent with the use of the same coupling facility structure
- You don't know in advance the journal names that will be used
by CICS applications.
Otherwise, it is probably less work to define the log streams explicitly
using IXCMIAPU.
The default model log stream names that CICS uses
for dynamic creation of a general log stream are of the form LSN_qualifier1.LSN_qualifier2.MODEL
where the first and second qualifiers are the CICS region
userid and the CICS APPLID, respectively.
Example: If a CICS region,
running under userid CICSHA## with APPLID=CICSHAA1, issues a request
to create a general log stream that is not defined by a JOURNALMODEL
resource definition, CICS specifies CICSHA##.CICSHAA1.MODEL
as the model log stream name.
See Model log streams for CICS system
logs for information about using an XLGSTRM
global user exit program to modify requests to create a log stream.
Unlike system log streams, which are unique to one CICS region,
general log streams can be shared between many CICS regions.
This means that you can merge forward recovery data from a number
of CICS regions onto the same forward recovery log
stream:
- You can use the same forward recovery log stream for more than
one data set--you do not have to define a log stream for each
forward-recoverable data set.
- You can share a forward recovery log stream between multiple CICS regions.
If the regions are accessing a data set in RLS mode, the use of the
same forward recovery log stream is forced.
Your decision on how to define and allocate forward recovery log
streams is a trade-off between transaction performance, fast recovery,
and having a large number of log streams to manage.
Some things to consider are:
- You can share a coupling facility log stream across multiple CICS regions
that run in the same or in different MVS images.
You can share a DASD-only log stream only across CICS regions
that run in the same MVS image.
- All data sets used by one transaction should use the same log
stream (to reduce the number of log streams written to at syncpoint).
- Share a forward recovery log stream between data sets that:
- Have similar security requirements
- Have similar backup frequency
- Are likely to need restoring in their entirety at the same time.
- The last qualifier of the stream name is used as the CICS resource
name for dispatcher waits. Therefore, a self-explanatory qualifier
can be helpful when you are interpreting monitoring information and CICS trace
entries.
- Don’t mix frequently updated data sets with infrequently updated
data sets on the same forward recovery log, because this causes a
disproportionate amount of unwanted log data to be read during recovery
of infrequently updated data sets.
- Don’t put all frequently updated data sets on a single log
stream because you could exceed the throughput capacity of the log
stream.
- If you define too many data sets to a single log stream, you could
experience frequent structure-full events when the log stream can’t
keep up with data flow.
- Delete redundant data from log streams periodically, to preserve
secondary storage and so that the system logger does not exceed its
limit of data sets per log stream. (The limit is several million and
in normal circumstances it is not likely to be exceeded.) See the CICS Transaction Server for z/OS® Installation Guide for information about
managing log stream data sets.
- Relate log stream names to the data sets. For example, PAYROLL.data_sets
could be mapped to a forward recovery log named PAYROLL.FWDRECOV.PAYLOG.
- Avoid having too many forward recovery log streams, because of
coupling facility log structure limits.
[[ Contents Previous Page | Next Page Index ]]