Video: Using the ACF TEST Subcommand to test dataset access rules.

Document ID : KB000026247
Last Modified Date : 14/02/2018
Show Technical Document Details

Question:  

How do you use ACF TEST Subcommand to test dataset access rules?

Answer:  

This video will demonstrate how to use the ACF2 TSO ACF command processor TEST subcommand to test dataset access rules.

Click here to view the video.

This video 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.

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

Figure 1

Enter ACF to invoke the ACF command processor.

TYPE: ACF ( hit enter)

DISPLAY: TSO screen with "ACF" response

Figure 2

Note the ACF command processor responds with ACF, the response will be either ACF as shown here, or question mark based on your logonid's MODE setting. With MODE set in the logonid record, the response will be ACF, with NOMODE set the response will be question mark.

Enter ?SET LID? to establish the setting of the ACF subcommand to process logonid records.

TYPE: SET LID (hit enter)

DISPLAY: TSO screen with "LID" response

Figure 3

Next logonid USER01 is listed using the LIST subcommand.

TYPE: LIST USER01 (hit enter)

DISPLAY: TSO screen with the list of logonid USER01.

Figure 4

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.

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

Figure 5

Next the DEMO rule is decompiled with the DECOMP subcommand.

TYPE: DECOMP DEMO (hit enter)

DISPLAY: TSO screen with the decompiled DEMO rule

Figure 6

A copy of the decompiled DEMO rule has been saved in a notepad for reference in this demonstration.

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

Figure 7

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)

Figure 8

DISPLAY: test command access showing access is allowed.

Figure 9

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)

Figure 10

DISPLAY: test command access showing access is denied.

Figure 11

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')

Figure 12

DISPLAY: test command access showing access is allowed.

Figure 13

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.

This concludes the demonstration on the use of the ACF2 command processor ACF TEST subcommand to interactively test a compiled ACF2 dataset access rule.