Use a catch-all entry as the last entry in the ERO table to make it easier to determine where report retention is controlled. This will enable all reports in the CA View database to be under ERO retention, and you will only have to look in one place to determine report retention specifications.
Business Value:
The catch-all entry is a simple technique to define safe retention criteria to all reports in the database as a safety net, and it significantly reduces the risk of data loss due to human error.
Additional Considerations:
The following SARINIT parameters and ERO table entries can be used as an example for describing the benefits of a catchall entry:
NGENT=60 NGEND=3 EROOPT=YES EROPRO=NEW PRETAIN=TABLE
Include the following entry at the end of the ERO table:
/* ALL GENS=60 DGENS=3
Note: GENS=NGENT and DGENS=NGEND.
Since the ERO table is searched in entry sequence, this catchall table entry will match reports that have not been defined by any previous entry. Therefore, every report in the whole database will be under ERO retention and you will only have to look in one place to determine report retention.
The new online mode, JOB mode, lets you collect and retain job information independent from archived reports. In JOB mode, you can select jobs (instead of reports) and perform several actions. For example, you can browse, print, or email either the jobs or the data sets in the jobs. For details about JOB mode, see the Release Notes, User Guide, and Reference Guide.
In JOB mode, the entire job is visible to users who have access to the job. However, if users do not have access to any DD's in the job, those DD’s are not displayed. Security administrators should account for this consideration when they assign users to JOB mode. For example, if an operator uses the CA View database to check logs or exceptions, first verify that they have access to the DD’s and jobs information that they need. Next, if necessary, deny them access to potentially sensitive data that they do not need or should not access, for example, a payroll report from the job.
If denying users access to these kinds of reports and DD’s is problematic, then consider creating multiple data bases for different purposes, for example, one database for JOBLOG information and one or more databases for reports.
In a JOBLOG database, you typically store JOBLOG data for a short period and make the data available to all CA View users. Specify a maximum number of lines for files in this database, to limit the size of job logs that may contain a dump. For instructions to create and configure databases, see the Reference Guide.
Also consider creating one or more data bases for reports, according to authorization level. For example, you can create a Finance database to store reports that only users in the Finance group can access. Similarly, you can create an HR database to store reports that only users in the Human Resources group can access, and so forth. For information about implementing security, see the Reference Guide.
Consider using the SECLIST parameter of the SARINIT utility to specify whether a selection list shows all reports or only the reports that a user is authorized to access (view, email, print, and so forth). You use your external security product to specify which reports users can access, and you use SECLIST to specify which reports users can list. A request for a print of a job, or an email of a job, always includes only reports that are authorized for the requesting user.
Business Value:
Creating multiple databases according to authorization levels helps you secure your data efficiently and effectively. Using SECLIST lets you specify which reports users can list.
|
Copyright © 2015 CA Technologies.
All rights reserved.
|
|