Extended Definition Mode

Initial Access to the Rule Status Screen (Screen OS)

For every action that is performed on this screen, security verifies authorization in which the CLASS checked is FACILITY and the entity checked is:

$$CTOPNLOS.qname

Subsequent Operations to the Rule Status Screen (Screen OS)

The actions (hold, free, delete, and so on) are separated into different categories of access authority. The CLASS checked is FACILITY, and the entity checked is:

$$RULxrrr.qname.owner

where

• owner is the owner specified in the rule definition.
• x is the one digit action identifier.
• rrr is the three character identifier for each action.

Valid actions and action identifiers are listed in the table below.

Table 63 Action Identifiers

The CTOSE08 module can be used to check for authorization to display individual lines on the Rule Status screen. Since a line-by-line authorization check affects performance, Control‑O invokes the CTOSE08 module when a user enters the Rule Status screen, but does not perform security checks. Users who want to limit the lines displayed on the Rule Status screen can use the Control‑O call to the CTOSE08 module to apply security checks at this stage.

To permit USERA to hold rules owned by USERB, use the following command:

For RACF:

PERMIT $$RUL2HLD.qname.USERB ACCESS(READ) ID(USERA) CLASS(FACILITY)

For TopSecret:

TSS PERMIT(USERA) IBMFAC($$RUL2HLD.qname.USERB) ACC(READ)

For ACF2/SAF:

SET RESOURCE(CMF)
COMP
$KEY($$RUL2HLD.qname.USERB) TYPE(CMF)
UID(USERA) ALLOW