Using Reports › Understanding the ACFRPTRV Report › What Do the Fields Mean?

What Do the Fields Mean?

Because CA ACF2 Option for DB2 journals events in the same SMF records as CA ACF2, standard CA ACF2 reports show both CA ACF2 and CA ACF2 Option for DB2 information. These fields are explained in the order in which they appear in the report formatted for the terminal. They are explained in terms of the CA ACF2 Option for DB2 information that might appear in them.

REQUESTED RESOURCE

Names the resource to which access is being requested. The resource is identified by the infostorage record key in the format below:

class‑type‑name

The segments of the infostorage key for a DB2 resource are explained below:

class and type

The storage class can be C(for control records) with a type code of DB2, or D(for CA ACF2 Option for DB2 rules) with a type code of one of the following:

Name

The name of the key consists of the four‑character DB2 subsystem ID followed by the resources name of the requested DB2 resource:

Note: Information contained in these reports might also include infostorage record keys for resource rules, which use different class and type codes, and different formats for the names of resources. In particular, an infostorage record key for a resource rule to validate SAF calls is formatted as follows:

R‑SAF‑xxxx.yyyyy

This key is explained in more detail in Appendix B, “Using SAF,” in the CA ACF2 Option for DB2 Planning and Installation Guide.

REC

Indicates whether the record is a logging, violation, or trace record. Violation records are highlighted with an asterisk (*) before this field.

LOOKUP KEY

Indicates the name of the CA ACF2 Option for DB2 rule set that was used to validate the request. This name shows any modifications to the resource name from the DB2PRE Prevalidation exit or the CA ACF2 directory.

UID

Lists the requester’s user identification string (UID).

SOURCE

Shows the logical input source where the resource request was issued.

CPU

Lists the SMF name of the CPU that validated this resource request.

MODULE

Names the requesting module as identified in the CA ACF2 Option for DB2 request parameter list. This might be a user‑supplied name. A possible CA ACF2 standard value is:

LOGON

TSO logon processing validation.

DISP

Names the element that determined the disposition of this request:

NO‑REC

A record matching the requested resource was not found in the CA ACF2 Infostorage database.

NO-RULE

A rule entry matching the environment of the request was not found in the rule set.

RULE

An CA ACF2 Option for DB2 rule entry determined the disposition of this request.

DSPMOD

Details the various exits and conditions that can modify the disposition.

PRE-VALD

A user DB2PRE Prevalidation exit altered the final request disposition.

PST-VALD

A user DB2POST Postvalidation exit altered the final request disposition.

NON-CNCL

The requester’s logonid was not canceled so the request was permitted.

SEC-OFF

The requester was a security administrator so the request was permitted.

ABORT

The request was unconditionally aborted.

KEYMOD

Indicates the resource validation component that modified the key. CA ACF2 modifies the resource name to perform a database lookup operation.

PRE-VALD

The user DB2PRE Prevalidation exit altered the request key.

DIRECTRY

A CA ACF2 directory matched the key and modified it.

PREV/DIR

Both the user DB2PRE Prevalidation exit and the CA ACF2 directory modified the request key.

SERV

Shows the type of service requested for a particular DB2 resource. This field corresponds to the DB2 privilege or authority, which is shown in parentheses in the following table. The possible three‑ to four‑character abbreviations for each type of resource are as follows:

1ADM is not a privilege or authority that you can grant in a rule set. Because CA ACF2 Option for DB2 prevents users from creating views with more authority than they have on the base tables or views, CA ACF2 Option for DB2 reports ADM in this field when a creator of a view can change the view rule set but not the base table or view rule set. Also, it is reported against the base table or view, not the view being created. See “Creating Views” in the Processing Security Information section in “Comparing DB2 and CA ACF2 Option for DB2 Features,” chapter for more information about creating views.

2CREATE is not an IBM DB2 privilege or authority. CA ACF2 Option for DB2 uses it as a check to determine whether a user can create or drop a view. See the section discussed above for more information about creating views.

An entry in the RV report with SERVICE(OWN) is a request for OWNERSHIP. Ownership is not a SERVICE and cannot be specified in the SERVICE parameter of a rule. Ownership in a rule is established with the $LIDOWNER control statement, giving ownership to a certain unique logonid, or with the $UIDOWNER control statement, giving ownership to one or more individual logonids that match the UID mask.

DATE

Notes the Julian and Gregorian date on which the request was made. Through the CA ACF2 Global System Option (GSO) OPTS DATE, you can specify MM/DD or DD/YY for the Gregorian format.

TIME

Documents the time at which the request was made.

JNAME

Identifies the name of the job under which the access was issued. If this is a TSO session, the job name and the logonid are generally the same.

LID

Identifies the logonid of the user making the request.

NAME

Shows the name of the user making the request.

PRE

Documents the return code from the user DB2PRE Prevalidation exit. Possible return codes are:

0—Continue normal processing

4—Logonid not found

8—Allow and log request

20—Prevent request

RMC

Shows the return code from the CA ACF2 record manager. Possible return codes are:

0—Record was already resident

4—I/O needed to obtain record

8—Record was not found

INT

Shows the return code from the rule interpreter. Possible return codes are:

0—Allow request

4—Allow and log request

16—Prevent access

20—No rule applies

24—Rule record not proper format

PST

Shows the return code from the user DB2POST Postvalidation exit. Possible return codes are:

0—Continue normal processing

4—Allow request

8—Allow and log request

20—Prevent request

FIN

Indicates the final return code from the CA ACF2 resource validation function. Possible return codes are:

0—Allow

4—Allow and log

16—Prevent request

PRIMARY AUTHID

Specifies the ID that a process, or a user, is associated with during a DB2 session. An exit can set this ID prior to connecting to DB2.

ORIGINAL AUTHID

Indicates the ID that the user is associated with before a DB2 exit changed it. Typically, the primary and the original authorization IDs are the same, but a DB2 exit can change it.

SECONDARY AUTHIDS

Lists all of the secondary authorization IDs a user is associated with through a DB2 exit. These IDs give the user privileges that are added to the privileges of his primary authorization ID.