Program access to data sets (PADS) in BASIC mode

Program access to data sets allows users or groups of users to access data sets with higher authority than they would normally have, but only while running a specified program. This is useful when using a program that in some way restricts the user's view of the data, by applying additional validation to some action the user wants to take.

To set up program access to data sets, create a conditional access list for the data set profile protecting the data sets. To do this, specify WHEN(PROGRAM(program_name)) with the ID and ACCESS operands on the PERMIT command. This specification grants the higher access only while the users run that program.

Restriction: Specifying ALTER in a conditional access list usually provides authority no greater than UPDATE (for non-VSAM data sets) or CONTROL (for VSAM data sets). Specifically, ACCESS(ALTER) with WHEN(PROGRAM(…)) does not allow users to delete or allocate the data set through JCL. Deletion or allocation only works through PADS when the program internally performs the deletion or allocation itself by invoking the appropriate system functions, but this is not typical behavior for most programs.

To understand which programs to specify in the conditional access list you need some information about how the user invokes the program and how the program operates. Several cases are illustrated at a high-level. Some of these cases are complex because of the rules that RACF® must enforce in order to ensure a secure environment. Therefore, you might need to know more about the design of an application or the way a TSO user invokes a program than you already know. Such cases are described in greater detail but you might want to involve a systems programmer to evaluate them.

The user invokes the program PROG1 through JCL:
```
//stepname EXEC PGM=PROG1
//ddname DD DSN=some.dataset,DISP=SHR or OLD or MOD
```
Program PROG1 issues the OPEN for some.dataset itself. In this case, make sure that you have defined PROG1 in the PROGRAM class as a controlled program and specified PROG1 in the DATASET class on the conditional access list:
```
RDEFINE PROGRAM PROG1 UACC(READ) 
ADDSD 'some.dataset' ACCESS(NONE)
PERMIT 'some.dataset' ID(userid or *) WHEN(PROGRAM(PROG1)) Accessories or UPDATE)
```
For the ID operand, you can supply a specific user ID or group name, or you can specify * to indicate that any user allowed to run the program gets that access level if the standard access list did not grant a sufficient security level. If you define PROG1 with a specific PROGRAM profile, such as PROGRAM PROG1, and provide a specific access list for that profile, you might want to use ID(*) in the conditional access list so you have only one access list (PROGRAM PROG1) to maintain. If you define PROG1 through PROGRAM ** or if you grant UACC(READ) or ID(*) ACCESS(READ) to PROGRAM PROG1, you might want to supply a specific user ID or group name in the conditional access list for some.dataset.
The user invokes the program (PROG1) at the TSO/E READY prompt:
- Directly as a TSO command using the TSO/E CALL command
- Through a REXX exec that uses one of the following REXX statements:
  - address LINKMVS
  - address LINKPGM
  - address ATTACH
  - address ATTCHMVS
  - address ATTCHPGM
PROG1 then issues the OPEN itself.
Keeping a clean environment is generally harder to manage in TSO than in batch. As a result, you must take more care with the definition of PROGRAM ** than for the batch case. However, assuming that you have kept the user's environment clean by defining the appropriate programs and libraries, this case is the same as the batch case above and it is not described further.

Guideline: For the use of CALL or the REXX functions, make sure you use NOPADCHK when defining the entries in PROGRAM **. If you use PADCHK, you might need to define additional programs in the conditional access list.
The user invokes the program (PROG1) under ISPF:
- Directly as a TSO command or using the TSO/E CALL command
- Through the ISPF SELECT CMD(PROG1) or SELECT PGM(PROG1) functions
- Through a REXX exec that uses one of the following REXX statements:
  - address LINKMVS
  - address LINKPGM
  - address ATTACH
  - address ATTCHMVS
  - address ATTCHPGM
PROG1 then issues the OPEN itself.
This case is very similar to case 2 above. However, it raises the additional possibility that the user is running in ISPF split-screen mode. In split-screen mode, the user might have initiated several programs and they might all be active at the same time. Suppose that the user has split his ISPF screen, and has program PROGA active on the first screen while trying to run PROG1 on the second screen. In this case, in order for PADS to work for PROG1, PROGA must be defined to RACF, as well. If you defined it with the NOPADCHK attribute, you can simply specify PROG1 in the conditional access list as you did for cases 1 and 2 above. However, if you defined it with PADCHK, you must have a second conditional access list entry granting PROGA authority to the data set. For this situation, you would issue the following commands.
```
RDEFINE PROGRAM PROG1 UACC(READ) 
RDEFINE PROGRAM PROGA UACC(READ) 
ADDSD 'some.dataset' ACCESS(NONE)

PERMIT 'some.dataset' ID(userid) WHEN(PROGRAM(PROG1) 
   ACCESS(READ or UPDATE)
PERMIT 'some.dataset' ID(userid or *) WHEN(PROGRAM(PROGA) 
   ACCESS(READ or UPDATE)
```
The user invokes PROG1 under TSO as above (cases 2 or 3), but you cannot keep his environment clean. For example, perhaps the user must run programs that you do not want to define as controlled programs because you do not trust them. In that case, when the user runs such programs the environment becomes dirty, and subsequently he cannot invoke PROG1 in a normal fashion if you want PADS to work.
If you have this situation, and if PROG1 does not need to invoke ISPF services through ISPLINK, you can still allow use of PADS by having the user run PROG1 through the TSO/E TSOEXEC command or (from another program) by the TSO/E IKJEFTSR callable service. Both of these mechanisms can create a new, temporary program environment that is clean and safe to use with PADS. The user might invoke PROG1 by issuing TSOEXEC PROG1 or TSOEXEC CALL *(PROG1) or some similar operation (such as a REXX exec or CLIST). You can then specify PROG1 in your conditional access list as you did for cases 1 and 2 above. Note that for this case, even if the user is using ISPF split-screen mode, you do not need to worry about putting other programs in the conditional access list.
The user invokes PROG1, and PROG1 invokes another program PROG2, and PROG2 OPENs the data set.
Assumptions:
1. You have defined both PROG1 and PROG2 as controlled programs using the NOPADCHK attribute.
2. PROG1 invokes PROG2 through the MVS™ LINK or ATTACH services. If PROG1 issues MVS LOAD for PROG2, you just define PROG1 in the conditional access list (allowing you to skip Step 6 below). Conversely, if PROG1 invokes PROG2 through the MVS XCTL service, you just define PROG2 in the conditional access list (allowing you to skip Step 6 below).
3. The user invoked PROG1 through some function that uses the MVS ATTACH service:
  - JCL
  - Directly as a TSO command
  - Through TSOEXEC or IKJEFTSR service
  - Through ISPF SELECT CMD(PROG1),
  - Through one of the following REXX statements:
    - address ATTACH
    - address ATTCHMVS
    - address ATTCHPGM
Considering these assumptions, you have two ways of specifying your conditional access list:
1. Since PROG2 issues the OPEN, you can specify WHEN(PROGRAM(PROG2)). You do not need to mention PROG1 in the conditional access list unless you defined PROG1 with PADCHK.
2. Starting with z/OS Version 1 Release 4, you can specify WHEN(PROGRAM(PROG1)). You do not need to mention PROG2 in the conditional access list unless you defined PROG2 with PADCHK.

Note: With programs written in IBM's C, C++, COBOL, or PL/I, you can usually specify the name of the main program in the conditional access list.

Rules:

When you are creating an entry in a conditional access list, the program name you specify cannot contain any generic characters. For example, if you specify WHEN(PROGRAM(*)), WHEN(PROGRAM(IKJ*)), or WHEN(PROGRAM(ABC00%), the entry does not grant any authority. You must specify the exact program name. For more information, refer to z/OS Security Server RACF Command Language Reference.
In certain cases, if you have a program (such as PROG1) that runs under ISPF and uses the ISPF LMOPEN service to open a data set, you can grant access using PADS. In order to do this, the user's ISPF dialog must invoke PROG1 using SELECT PGM(PROG1). PROG1 can then use ISPLINK to invoke LMOPEN. You must then specify WHEN(PROGRAM(PROG1)) in the conditional access list.
Program access to data sets does not allow different programs with the same name to exist in different libraries requiring different access levels. For example, if you have a program PROGA in library 'load.library1' and also have a program PROGA in 'another.load.library', there would be no distinction between these programs in the conditional access list.
ALTER access authority in a conditional access list does not allow the creation or deletion of the data set through JCL. To create or delete a particular data set while running a particular program, and if the data set is to be allocated through JCL, do not grant ALTER authority through PADS. At the time the system creates or deletes the data set through JCL, the program specified in the JCL is not running, and PADS cannot work. You can only allow the creation or deletion of a data set through PADS if the program asks the system to allocate or delete the data set during execution, which is not typical of normal program behavior.
To allow the allocation or deletion of data sets through PADS, write an application to use dynamic allocation (SVC99) to allocate a data set rather than allocate it using JCL. The creation of the data set while running the new program can be allowed, and the new program can then invoke the original application program.

Note: As mentioned in case 5 above, beginning with z/OS® V1R4, you have more flexibility in specifying programs in a conditional access list. To explain this, some familiarity with certain MVS technical terms is necessary. Generally, programs run under MVS tasks. A program running in one task can attach a subtask (also known as a child task) using the MVS ATTACH service. A program can also invoke another program within the same task (rather than a subtask) using the MVS LINK service. MVS represents a task by a control block called a TCB, and it represents a program running in a task (TCB) with a program request block (PRB). As a result, if a program invokes another program through LINK, you now have one task (TCB) with two programs (PRBs).

When considering what program to specify in the conditional access list, you can use either the program issuing the OPEN (current PRB, in MVS terms) or you can specify one of the following:

The program represented by the first PRB for the current task (generally the first program run in the task, unless that program used the MVS XCTL service to transfer control to another program)
The program represented by the first PRB for the current task's parent task, or the parent task's parent, up to the job step task or the task established by TSOEXEC or IKJEFTSR.

Consequently, if:

The user executes PROG1
PROG1 LINKs to PROG2
PROG2 issues the OPEN

you can specify PROG2 or PROG1 in the conditional access list.

If:

The user executes PROG1
PROG1 LINKs to PROG2
PROG2 ATTACHes PROG3
PROG3 LINKs to PROG4
PROG4 issues the OPEN

you can specify:

PROG4 (program issuing OPEN)
PROG3 (first PRB in current task)
PROG1 (first PRB in parent task)