4. IMS communication with DBRC is performed through the use of
threeVSAM KSDS data sets, called Recovery Control (RECON)
data sets.
The RECON data sets contain all of the recovery information used
in recovering registered databases.
RECON data sets contain several types of records, each of which is
associated with a particular function of DBRC
A RECON header record is created for each RECON data set to
provide information that DBRC uses in managing the
system. Other records are created to maintain log control, change
accumulation, image copy, database data set, reorganization, and
recovery information.
5. DBRC controls the use and availability of
OLDS(online log datasets), SLDS, RLDS, and
interim log data sets.
Information about the logs is stored in a set of
RECON data set records called log data set
records.
If you requested dual logging, they are referred
to as PRILOG (the primary log) and SECLOG,
(the secondary log). DBRC also creates log
allocation (LOGALL) records to identify a
database that was changed while its log data
set was open.
6. DBRC controls the recovery of databases by supplying
the necessary input for the IMS Recovery utility.
To use the recovery control portion of DBRC, you
must register your databases with DBRC.
Recovery control does not choose the correct utility
to be run at the correct time. For example, you must
select the correct utility to run in the following
circumstances:
▪ image copy after reorganization
▪ recovery after database I/O error
▪ backout after batch failure
▪ /ERE after online failure
7. A full recovery means that you have restored all
of the database updates that were performed
since the image copy was taken.
It requires a valid image copy of the database,
all log data sets created since the image copy
was taken, and any change accumulation data
sets.
A full recovery is most often used when the data
has not been corrupted but the database has
been lost through something like a hardware or
reorganization failure.The data was not
corrupted; the database simply crashed.
8. A time stamp recovery recovers the database to
a selected point in time.
A time stamp recovery can use any image copy
of the database.Then updates (using logs and
change accumulation data sets) are applied up
to a selected point in time.
A time stamp recovery is usually used when the
database has been corrupted through a
processing error such as faulty application logic.
9. This can be achieved by registering database
with dbrc, and to define share level
SHARELEVL 0
No sharing. The database can be accessed only by the
subsystem to which it has been authorized.
SHARELEVL 1
Database-level sharing. The owner subsystem can perform
updates, but other subsystems are read only.
SHARELEVL 2
Intra-host block-level sharing. Subsystems executing on the
same MVS have full update authority.
SHARELEVL 3
Inter-host block-level sharing. Subsystems operating on the
same (or any other) MVS have full update authority.
10. Read more at:
ftp://service.boulder.ibm.com/eserver/zseries/au
dio/pdfs/Part_12_V9_DBRC.pdf