EROPRO and Retroactive Retention Processing

Products

• OM View

Issue/Introduction

Adding multiple new sysout qualifiers into ERO table and would like to extend the retentions for those like named reports which are already in the database. Currently EROPRO=NEW specified.

Resolution

There are two types of report retention processing available in View.

The first type 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. For example, if three standard backup cycles are run daily, then one day is equal to three database generations.

This type a report retention is referred to as NGEND/NGENT and is defined using the below two database initialization parameters,

NGEND=nnnn
The NGEND option indicates to View how many generations a report should be retained on disk before the disk copy of the report should be deleted. 

NGENT=nnnn
The NGENT option indicates to 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) which 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. that is, reports which are currently under control of NGEND/NGENT. 

EROPRO=NEW
The EROPRO Option 'NEW' indicates to 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. 

EROPRO=YES
EROPRO=ALL 
The EROPRO Options 'YES' and 'ALL' indicates to View that all reports, new and old, should be evaluated for Expanded Retention even if they were never under ERO control. 

Note: It is recommended that EROPRO be set to and left as YES unless a large percentage of the database is under NGEND/NGENT. 

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 View System Reference Guide, "Restplete Disk Archival Generoring a Comation (SARTDR)", under the SARTDR Control Statements says: If you have ERO, set the SARINIT initialization parameter EROPRO to YES and run a standard backup cycle. 

This requirement is no longer 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 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 table entry. 

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.