Providing Users with UPDATE access to View Databases

Products

• Deliver
• View

Issue/Introduction

In an upgrade, whereas the client only had VTAM access for their users (using a modified SARUSAUX exit) and everyone had READ access to the databases, the client now would like for everyone to be able to access CA View through TSO ISPF, but now their users would require UPDATE access to the View databases.

What are the items that need setting so that the client will be able to allow everyone access through TSO ISPF, but only with READ access to the databases?
 

Environment

CA View - All Releases

Resolution

Here is the security information provided to the client:
 . The end-user must have:
 . . CA Top Secret - Update access - To save user profile information, such as last access date, current access mode.
 . . CA ACF2 ....... - Write access - To save user profile information, such as last access date, current access mode.
 . . RACF ............ - Update access - To save user profile information, such as last access date, current access mode.

 . The direct above does NOT allow a user to delete, rename, scratch, etc., the database extents.
 . It is suggested to review the "Security" chapter in the View Reference Guide, working alongside with a Security Administrator.

  Examples on how to define and implement security (for Top Secret, ACF2, and RACF) are in the Security chapter, as well as there being samples in the CVDEOPTN library (SARTSS, SARACF, SARRACF).

 The information is detailed on how View works with external security and how to build the necessary rules for the users, regarding:
  . . Resource types
  . . Access level needed for function the user is attempting
  . . CPL function type
  . . The function the user is attempting

 . NOTE: Setting the SARINIT paramter FEATURE=1 will write the resource rules, to the task log, that are necessary when users attempt any action.
  This will greatly assist the security group with rules needed or being missed.
   When setup is complete, remove FEATURE=1 by running SARINIT without '1' in the FEATURE parameter.

 . Once the user is logged on to View, the external security page rules for the resources, as defined for the users, govern what access is granted for all of a user's attempted functions.
 . Note: Executing the View utilities via batch jobs are also governed by the external security rules.

 . To secure a database's extents from any external products and/or program, the external security package can accomplish that, however, View function SARXTD can be used, which will deny all access for an external entity attempting to access the database.
 Only View's utilities will get access, however, the user resource/function rules may deny the user access even if the function is with a View utility, and will not deny a user access utilizing one of the View utilities, if they were granted access for the user resource/function.

 . Lastly, some clients customize their SARSECUX exit, and some use CVDEOPTN(SARATHU1) in their preparation of the SARATHUX exit.
 . Please note that CA will not analyze nor work on any custom security exits.