Using the ACF TEST Subcommand to test dataset access rules
search cancel

Using the ACF TEST Subcommand to test dataset access rules

book

Article ID: 26247

calendar_today

Updated On:

Products

ACF2 ACF2 - z/OS ACF2 - MISC

Issue/Introduction

How can the ACF TEST Subcommand be used to test dataset access rules?

Resolution

This article will demonstrate how to use the ACF2 ACF command processor TEST subcommand to interactively test a compiled ACF2 dataset access rule.

  • The TSO ACF command processor provides subcommands to process ACF2 rules and records.
  • The ACF command processor can be invoked from the TSO READY prompt, or i f you are in ISPF, you can issue the TSO ACF command from the command line.

  • The TEST subcommand lets you determine whether a rule set provides the access you want. When you use the TEST subcommand, ACF2 performs a full validation of the compiled rule, but does not create any loggings for violations.

  • Test results comply with the ACF2 MODE that ACF2 is actively running.

  • User exits can affect the outcome of the test command for data set rule testing.

 

 

Issue the ACF command and LIST the logonid

First we will use ACF commands to list the logonid that we will be using in this demonstration.

When the TSO READY message appears at the terminal, you can issue the ACF command.

DISPLAY: TSO screen with READY PROMPT

Enter ACF to invoke the ACF command processor.

TYPE: ACF ( hit enter)

DISPLAY: TSO screen with "ACF" response

Next logonid USER01 is listed using the LIST subcommand.

TYPE: LIST USER01 (hit enter)

DISPLAY: TSO screen with the list of logonid USER01.

Note the UID string for logonid USER01 that will be used in testing. Also note that the USER01 logonnid does not have any special privileges such as NON-CNCL or SECURITY.

Issue the SET RULE command and DECOMP the rule

Next the dataset access rule DEMO will be decompiled. This is the rule that we will be using with the TEST subcommand.

Enter SET RULE to establish the setting of the ACF subcommand to process dataset access rules.

TYPE: SET RULE (hit enter)

DISPLAY: TSO screen with "RULE" response

Next the DEMO rule is decompiled with the DECOMP subcommand.

TYPE: DECOMP DEMO (hit enter)

DISPLAY: TSO screen with the decompiled DEMO rule

Issue the TEST command

We will perform 3 different tests of the DEMO dataset access rule.

Here we issue the TEST subcommand specifying DEMO, the ruleid that we are testing. Note that if the rule to be tested was just decompiled or compiled, TEST * can be specified.

TYPE: TEST DEMO (hit enter)

DISPLAY: TSO screen with the period response

When the period (.) is displayed, the TEST subcommand is active. Enter any of the TEST subcommand keywords to specify the particular environment that you want to test.

TEST 1

The first environment to be tested is for USER01 for read access to dataset DEMO.LEVEL2.LEVELX. The DSN parameter specifies the dataset in quotes, the UID parameter specifies the UID string for USER01 and read is specified for the ACCESS.

TYPE: dsn( 'DEMO.LEVEL2.LEVELX') uid(XY USER01) access(read)

DISPLAY: test command access showing access is allowed.

From the TEST command output we see access is allowed based on rule entry:

LEVEL2 .- UID(XY) READ(A) EXEC(A)

The dataset 'DEMO.LEVEL2.LEVELX' matches the rule entry with LEVEL2.-, the UID string matches USER01's UID string and READ( A) matches the requested READ access, so access is allowed.

TEST 2

The second test environment is the same as the previous test, except the ACCESS to be tested is for WRITE. The DSN parameter specifies the dataset in quotes, the UID parameter specifies the UID string for USER01 and WRITE is specified for the ACCESS.

TYPE: dsn( 'DEMO.LEVEL2.LEVELX') uid(XY USER01) access(write)

DISPLAY: test command access showing access is denied.

From the TEST command output we see that access is denied based on rule entry:

LEVEL2 .- UID(XY) READ(A) EXEC(A)

The dataset 'DEMO.LEVEL2.LEVELX' matches the rule entry with LEVEL2.-, the UID string matches USER01's UID string but only READ and EXECute is allowed, WRITE and ALLOCate are denied. So in this case access is DENIED for WRITE ACCESS.

TEST 3

This third test environment includes multiple environmental parameters. In this example we will TEST USER01 for write access to DEMO.LEVEL3.DATA on volume TEST01 using program MYPGM, from library SYS1.TESTLIB, and from the source A99LO900

TYPE : dsn ('DEMO.LEVEL3.data') lid(USER01) access(write) program(mypgm) -
SOURCE( A99LO900) VOL(TEST01) LIB('SYS1.TESTLIB')

DISPLAY: test command access showing access is allowed.

From the TEST command output we see access is allowed based on the rule entry:

LEVEL3 .- UID(XY) LIB('SYS1.TESTLIB') PROGRAM(MYPGM) -
SOURCE( A99LO900) VOL(TEST01) READ(A) EXEC(A) WRITE(A)

The dataset 'DEMO.LEVEL3.data' matches the rule entry with LEVEL3.-, the UID string matches USER01's UID string, the volume, program, source and access of write match so in this test access is allowed.