There are two types of report retention processing available
in CA-View. The first type which is part of the base product,
retains reports based on database generations.
A database generation is equivalent to a standard backup
cycle, in other words, every time a standard backup cycle
is executed, the database generation is incremented. If
three standard backup cycles are run each day than a day
is equal to three database generations.
This type a report retention is referred to as NGEND/NGENT
and is defined using the two database initialization
The NGEND option indicates to CA-View how many generations
a report should be retained on disk before the disk copy
of the report should be deleted.
The NGENT option indicates to CA-View how many generations
the report should be retained in the system, that is, on
tape. Since a report will be written to tape during the
first backup cycle, it is available in two locations, disk
and tape so the value includes NGEND, that is, if NGEND=10 and
NGENT=30, the report will remain on disk for 10 generations
and a total of 30 generations.
The second type of retention, Extented Retention Option (ERO)
is available as an optional feature.
The retention options are defined using database initialization
parameters and an ERO Table. Refer to the System Reference Guide
for additional details concerning the various options.
The ERO Processing Initialization Parameter, EROPRO, relates
to reports which have never been under ERO control not to ERO
Table changes, that is, reports which are currently under control
The EROPRO Option 'NEW' indicates to CA-View that only
newly archived reports should be evaluated for Expanded
Retention. Reports from older generations which were never
under ERO should not be considered.
The EROPRO Options 'YES' and 'ALL' indicates to CA-View
that all reports, new and old, should be evaluated for
Expanded Retention even if they were never under ERO
NOTE: It is recommended that EROPRO be set to and left as YES
unless a large percentage of the database is under
WARNING: These parameter settings do not control retroactive
processing. Once a report has been defined to ERO, it will always
remain under ERO control. All ERO controlled reports are
eligible for retroactive processing. A report which has been
under ERO control whose ERO Table entry has been removed and no
other ERO Table entry will apply, will be retained under PCOPIES.
Since this parameter defaults to a very small value, a report
may be deleted.
Reports which have been TADDed to a database because of some
recovery issue, fall under a different category and are not
considered 'OLD'. They are marked as 'recently TADDed' and
will be evaluated regardless of the setting of the ERO PRO
parameter. The comment in the CA-View System Reference Guide,
"Restoring a Complete Disk Archival Generation (SARTDR)", under
the SARTDR Control Statements says:
o If you have ERO, set the SARINIT initialization
parameter EROPRO to YES and run a standard backup cycle.
This requirement is no long required as recently TADDed reports
will be evaluated for ERO before any retention action is taken.
Once a report has been evaluated for ERO, it is always reevaluated
during every standard backup cycle. The definition for the EROPRO
parameter implies that there may be performance issues if this
parameter is set to 'YES' or 'ALL'. This is only true if a very
small percentage of reports are controlled under ERO and the larger
percentage are controlled under NGEND/NGENT. When a large percentage
of reports are controlled outside of ERO, there is no purpose of
attempting to match their report ids against each and every ERO
Changes to an ERO Entry in the ERO Table are retroactive and all
reports meeting this criteria are re-evaluated regardless of the
setting of the EROPRO parameter. Reports under ERO control are
always matched against the ERO table entries to determine if
changes in retention have occurred.