Previous Topic: Sample Resource Rule SetNext Topic: Rule Set Control Statements


Resource Rule Set Components

A resource rule set consists of the following:

  1. Control statements (identified by the $ or % symbols in the first column).
  2. Comment statements that are also rule set statements (identified by the * symbol in the first column).
  3. Rule entries (must all follow the control statements). When you enter a rule as input from a terminal or create or update a file used as compiler input, the rule input text must begin in the second column. If a rule entry is too long for one line, enter a blank and a dash at the end of the line to indicate that this rule entry is continued on the next line. The continuation line must begin in the second column.

A resource rule set is similar to an access rule set except that it is associated with a type code and has some structural differences. The complete syntax for a resource rule set is:

$Key(resource)
$Type(typecode)
 [ $Nosort                        ]
 [ $Prefix(prefix)                ]
 [ $Recname(record‑name)          ]
 [ $Userdata(text)                ]
 [ %Change uidmask1,uidmask2,...  ]
 [ %RChange uidmask1,uidmask2,... ]
 [ *comment                       ]
 [ rsrcmask                       ]
 [ UId(uidmask)                   ]
 [ SOurce(sourceid)               ]
 [ SHift(shiftname)               ]
 [ ACtive(date)                   ]
 [ UNtil(date)|FOR(days)          ]
 [ SERVICE(READ|UPDATE|ADD|DELETE)]
 [ Data(text)                     ]
 [ Nextkey(nextkey)               ]
 [ Reccheck(recordid)             ]
 [ Verify                         ]
 
  {Allow|Log|Prevent}

Any CMS file containing rule text exceeding 80 characters is changed into continuation lines. This makes editing and printing the file easier. The compiler accepts input files that already exist with record lengths up to 256 characters.

The components of this resource rule set are defined below.

$KEY(resource)

Indicates the resource name being compiled. This name can be up to 40 characters, depending on the resource rule application. For example, resource names for the CA ACF2 for VM‑defined type codes generally are one‑to eight‑characters long and often represent a value, such as a logonid. The TYPE value of the $KEY control statement specifies the three‑character type code that identifies the type of resource being protected.

$TYPE(typecode)

Specifies an alternate way to indicate the resource type. The resource type is generally specified on the $KEY control statement, as explained previously. The CA ACF2 for VM‑defined type codes are located in the TYPES field of the RESTYPE VMO record. These default type codes are listed in Types of Resource Rules section.

You can also use the ACFSERVE RELOAD RESOURCE subcommand to reload and create specific resource types. See the “Using the ACFSERVE Commands” chapter for detailed information about how to use this subcommand. Even though CA ACF2 for VM supplies these type codes, you can customize them to identify different type codes.

$NOSORT

Specifies that CA ACF2 for VM will not sort this resource rule set if you define the NOSORT parameter in the RULEOPTS VMO record.

$PREFIX(prefix)

Specifies a value that overrides the rule set key as a prefix to all resource names in this rule set. You can specify up to 24 characters. If you specify $PREFIX(), the prefix is set equal to the $KEY entry and the $PREFIX control statement is not generated when the rule is decompiled. CA ACF2 for VM issues a warning message indicating that the $PREFIX specified is null and is ignored (optional).

$RECNAME(recname)

Used for OS/390 record‑level protection. CA ACF2 for VM does not use this information. $RECNAME specifies the name of a RECORD definition record. For more information, see the CA ACF2 for VM for z/OS and OS/390 Administrator Guide.

Note: CA ACF2 for VM cannot maintain RECORD definition records.

$USERDATA(text)

Specifies any text string, up to 64 characters. Unlike the text in comment statements that is removed from the rule set at compilation time, the text on the $USERDATA control statement is stored with the rule set. You can also use the DATA parameter for a resource rule entry to store information in a rule entry.

%CHANGE uidmask1,uidmaskn,...

Specifies a mask (or masks) for the UIDs of users who can store and delete this rule set. The user or users given change authority can further delegate this authority to other users. Do not specify a dash (-) as a masking character at the end of a %CHANGE UID mask as CA ACF2 for VM interprets it as a continuation character. There is no need to specify this dash because all UID values are padded out to their full length.

%RCHANGE uidmask1,uidmaskn,...

Specifies who has restricted CHANGE authority over the rule set. The designated users can change individual rule entries, but not control statements. They cannot delegate change authority or delete the rule set. If the same user matches entries in %CHANGE and %RCHANGE, %CHANGE takes effect (optional).

Comment Statements

Indicates comment statements that begin with an asterisk (*) in column one and can appear anywhere in the input. They let you place any text inside an uncompiled rule set. This text is lost when the rule set is compiled. To retain comments when the rule set is compiled, use the $USERDATA control statement or the DATA parameter of a resource rule entry.

rsrcmask

Specifies additional qualifiers in the resource name. You must specify the
first‑level qualifier in the $KEY control statement to specify additional qualifiers for the rsrcmask parameter. CA ACF2 for VM places a period between the first and second level qualifiers.

You must specify rsrcmask as the first parameter in the rule entry. A resource name can be up to 256 characters, including the characters specified in the $KEY. You can use the dash masking character (just as in access rules) to represent any number of characters up to the 256 character limit. For example:

$KEY(PAYT) TYPE(CKC)
 EMPLOYEE.EMERGENCY.DATA.- UID(PAYUSR1) SERVICE(UPDATE)
 EMPLOYEE.- UID(PAYUSR) SERVICE(READ)

See the Access Rule Masking section in the “About Access Rules” chapter for more details on masking.

You cannot enclose the value you supply for rsrcmask in single quotes.

UID(uidmask)

Specifies a UID or mask of UIDs that identify the users attempting access. If you omit this parameter, it includes all users. UID masking in resource rules follows the same standards as UID masking in access rules.

SOURCE(sourceid)

Specifies the name of a source or source group where the access attempt is being made. If you omit this parameter, it includes all sources.

SHIFT(shiftname)

Specifies the one‑ to eight‑character name of the SHIFT record limiting the time, date, and day of the week when a user can access this resource. If you omit this parameter, it applies to any time or day.

ACtive(date)

Specifies a Gregorian date in the form mm/dd/uu, yy/mm/dd, or dd/mm/yy, (depending on the site option) that is the first date when this rule is considered valid. Note: See the DATE field of the OPTS VMO record for the site option information. Years specified as 70-99 assume a date in the 20th century (1970-1999). Years specified as 00-69 assume a date in the 21st century (2000-2069). This parameter is valid only when the VMO RULEOPTS RULELONG parameter is set.

UNTIL(date)

Specifies the last date an access can take place under this rule; that is, for the rule to apply, the access attempt must be on or before the UNTIL date. This date must be in the format specified in the DATE operand of the OPTS VMO record (mm/dd/yy, yy/mm/dd, or dd/mm/yy).

FOR(days)

Specifies the number of days from the compilation date of the resource rule set when a user can access under this rule. The minimum number that you can specify is zero (the compilation date). The maximum is 365. CA ACF2 for VM converts all values specified in this parameter to an UNTIL value when the rule is compiled.

SERVICE(READ|ADD|UPDATE|DELETE)

Specifies the type of access associated with the request. You can specify one or more keywords, separated by blank characters or commas. If you omit this parameter, all types of access are allowed. Keywords are:

READ

Read‑only access

ADD

Access to add new records

UPDATE

Access to modify existing records

DELETE

Access to delete records.

The SERVICE keyword is valid only for site‑specific resource rules and CA ACF2 for VM data space validation. For the resource rules specific to CA ACF2 for VM, it is ignored.

DATA(text)

Specifies up to 64 characters of data for your own use. This string is kept with the rule entry and displayed when the rule set is decompiled. Your site can have standards concerning the format of this character string. The data is passed to the site exits and back to the calling application subsystem with the global $USERDATA field. This data can indicate further checking or contain some control information.

VERIFY

Requests password validation for any access attempts made under this rule. The application subsystem requesting access to a resource is informed of the request for password validation. The VERIFY keyword is valid only for site‑specific resource rules. For the resource rules specific to CA ACF2 for VM, it is ignored.

NEXTKEY(nextkey)

Specifies the key of an alternate rule set that CA ACF2 for VM should check if access to this resource is denied based on this rule set. The NEXTKEY parameter functions the same in resource rules as it does in access rules. For more information, see the Using NEXTKEY section in the “About Access Rules” chapter.

Reccheck(recid)

Used for OS/390 record‑level protection. Specifies the name of an EXPRESSN record that you want CA ACF2 for VM to use for this validation. The EXPRESSN record defines a Boolean expression that CA ACF2 for VM evaluates to determine whether a user can access a record based on the contents of a field. For more information about EXPRESSN records and record‑level protection, see the CA ACF2 for VM for z/OS and OS/390 Administrator Guide.

You cannot use CA ACF2 for VM to maintain EXPRESSN records.

ALLOW

Specifies that access to the resource is allowed (without creating a logging record).

LOG

Specifies that access to the resource is allowed, but logged. CA ACF2 for VM writes an SMF record to log the event.

PREVENT

Specifies that access to the resource is prevented. CA ACF2 for VM writes an SMF record to log the event.

If you do not specify ALLOW, LOG, or PREVENT, PREVENT (the default) is assumed. The following sections explain the control statements and rule entry parameters.