Creating generic profiles for data sets

Suppose that SYSDSP is the RACF® user ID for Db2 started tasks in the following examples. DB2OWNER can issue the following commands to create generic profiles for the data sets and give complete control over the data sets to Db2 started tasks:

• For active logs, issue the following commands:

  ADDSD  'DSNC112.LOGCOPY*' UACC(NONE)
  PERMIT 'DSNC112.LOGCOPY*' ID(SYSDSP) ACCESS(ALTER)

• For archive logs, issue the following commands:

  ADDSD  'DSNC112.ARCHLOG*' UACC(NONE)
  PERMIT 'DSNC112.ARCHLOG*' ID(SYSDSP) ACCESS(ALTER)

• For bootstrap data sets, issue the following commands:

  ADDSD  'DSNC112.BSDS*'    UACC(NONE)
  PERMIT 'DSNC112.BSDS*'    ID(SYSDSP) ACCESS(ALTER)

• For table spaces and index spaces, issue the following commands:

  ADDSD  'DSNC112.DSNDBC.*' UACC(NONE)
  PERMIT 'DSNC112.DSNDBC.*' ID(SYSDSP) ACCESS(ALTER)

• For installation libraries, issue the following command:

  ADDSD 'DSN1310.*'          UACC(READ)

  Started tasks do not need control.

• For other general data sets, issue the following commands:

  ADDSD  'DSNC112.*'        UACC(NONE)
  PERMIT 'DSNC112.*'        ID(SYSDSP) ACCESS(ALTER)

Although all of those commands are not absolutely necessary, the sample shows how you can create generic profiles for different types of data sets. Some parameters, such as universal access, could vary among the types. In the example, installation data sets (DSN1310.*) are universally available for read access.

If you use generic profiles, specify NO on installation panel DSNTIPP for ARCHIVE LOG RACF, or you might get a z/OS® error when Db2 tries to create the archive log data set. If you specify YES, Db2 asks RACF to create a separate profile for each archive log that is created, which means that you cannot use generic profiles for these data sets.

To protect VSAM data sets, use the cluster name. You do not need to protect the data component names, because the cluster name is used for RACF checking.

The VSAM resource that is used to store the administrative scheduler task list must be protected in RACF against unauthorized access. Only the administrative scheduler started task user has the UPDATE authority on VSAM resources.

Access by stand-alone Db2 utilities: The following Db2 utilities access objects that are outside of Db2 control:

• DSN1COPY and DSN1PRNT: table space and index space data sets
• DSN1LOGP: active logs, archive logs, and bootstrap data sets
• Change Log Inventory (DSNJU003) and Print Log Map (DSNJU004): bootstrap data sets

The Change Log Inventory and Print Log Map utilities run as batch jobs that are protected by the USER and PASSWORD options on the JOB statement. To provide a value for the USER option, for example SVCAID, issue the following commands:

• For DSN1COPY:

  PERMIT 'DSNC112.*' ID(SVCAID) ACCESS(CONTROL)

• For DSN1PRNT:

  PERMIT 'DSNC112.*' ID(SVCAID) ACCESS(READ)

• For DSN1LOGP:

  PERMIT 'DSNC112.LOGCOPY*' ID(SVCAID) ACCESS(READ)
  PERMIT 'DSNC112.ARCHLOG*' ID(SVCAID) ACCESS(READ)
  PERMIT 'DSNC112.BSDS*'    ID(SVCAID) ACCESS(READ)

• For Change Log Inventory:

  PERMIT 'DSNC112.BSDS*' ID(SVCAID) ACCESS(CONTROL)

• For Print Log Map:

  PERMIT 'DSNC112.BSDS*' ID(SVCAID) ACCESS(READ)

The level of access depends on the intended use, not on the type of data set (VSAM KSDS, VSAM linear, or sequential). For update operations, ACCESS(CONTROL) is required; for read-only operations, ACCESS(READ) is sufficient.

You can use RACF to permit programs, rather than user IDs, to access objects. When you use RACF in this manner, IDs that are not authorized to access the log data sets might be able to do so by running the DSN1LOGP utility. Permit access to database data sets through DSN1PRNT or DSN1COPY.