View - Want to ensure that reports are backed to tape on day 1

Products

• View

Issue/Introduction

Customer is looking to ensure that independently on the ERO table, any report/sysout should be recoverable from tape from day 1 when they enter the CA View/Deliver database.

So for example, if a report is set to remain 5 days on the primary storage (DASD) before being moved to secondary storage, they want that same report to also be on tape on the 1st day of that 5 days period when it's residing on disk.

I think, and that's what I would like to confirm, that this is already achieved when we run our backup cycle everyday.

Environment

Release : 14.0

Resolution

The way that View conventionally works is:

 - Reports are collected to disk (SARSTC, SARFSS, Deliver). 
 - At the next View backup, the report is written to tape. 

 - Now, as the report resides on both disk and tape, the retention parameters are applied, determining how long to keep the report on disk, and how long to keep the report on tape. 

If the Sysout ID matches one of the sysout_IDs in the ERO table, those retention parameters will be used. 

For those Sysout IDs where there is not a match in the ERO table, it will then use the SARINIT NGEND and NGENT parameters. 

ERO Example ...
 /ABC*   ALL RETPD=90 DRETPD=7

Above, reports that start with ABC... and created by any jobname, will be retained on disk for 7 days and on tape for 90 days.

If you have SARINIT EROPRO=NEW (the default), and you change it to EROPRO=ALL or EROPRO=YES (preferred), retentions will be applied to the whole database. After EROPRO=ALL, the parameter resets to EROPRO=NEW.

Please see the below, on the EROPRO parameter:

https://techdocs.broadcom.com/us/en/ca-mainframe-software/traditional-management/ca-view/14-0/reference/initialization-parameters/expanded-retention-parameters.html

 - The default is NEW.
 - Values are as follows:
 - - NEW
 - - - Only SYSOUTs in the current generation are eligible to switch to ERO retention.
 - - YES
 - - - All SYSOUTs are considered, and the parameter is not reset to NEW at the end of the backup cycle.
 - - ALL
 - - - A one-time request to reconsider the entire database, and the parameter is reset to NEW at the end of the backup cycle.