Simple program protection in BASIC or ENHANCED mode

If you have a need to prevent a user or group from executing a particular program, you can define a profile for that program in the PROGRAM class and issue the PERMIT command to specify an access level of NONE for the program. This simple usage of program control does not depend on making any other PROGRAM definitions or on keeping the environment clean. You can also use this simple form of program control to audit usage of a program. If you only need to audit usage of the program and do not need to control which users can execute it, grant all users READ access and set the AUDIT operand appropriately.

A program protected by a PROGRAM profile is sometimes called a controlled program. To protect a program with a PROGRAM profile, use the RDEFINE command and specify the name of the program as the profile-name. You must also specify the ADDMEM operand and indicate:

Name of the library that contains the program (required)
Volume serial of the DASD volume that contains the library (optional)
PADCHK or NOPADCHK option (optional; see Choosing between the PADCHK and NOPADCHK operands for more information.)

The PROGRAM profile can also contain other information, such as the following:

UACC
Standard access list
Conditional access list

Specific and nonspecific profile names: The name of the PROGRAM profile can be completely specified, in which case the profile protects only one program name. This type of PROGRAM profile is known as a specific PROGRAM profile because it protects one specific program name. The name of the PROGRAM profile can also end with an asterisk (*), in which case the profile can protect more than one program name. This type of PROGRAM profile is known as a nonspecific PROGRAM profile.

Example: A PROGRAM profile named ABC* protects programs whose names begin with ABC (including a program named ABC) and reside in the library specified using the ADDMEM operand unless another profile name matches more characters of the program name.

If you have two PROGRAM profiles named ABC* and ABC, and both profiles specify the name of the library where the ABC program resides, RACF® uses the ABC* profile for authorization checking of program ABC, not the ABC profile.

If you want to control the ABC program with a specific profile named ABC, you can use one of the following methods:
- Move the ABC program to a separate library and alter the ABC profile using the ADDMEM operand of the RALTER command to specify the new library and the DELMEM operand to remove the old library. (You will also need to change the way you invoke the ABC program to ensure that the new copy is used.)
- Delete the ABC* profile and define a set of new profiles named ABCx* profiles where x is the next character that matches your program names that begin with the characters ABC. For example, if you have programs named ABCJA, ABCJB, ABCLA, and ABCLB, define profiles named ABCJ* and ABCL* to protect them.
If you want to control the ABC program with a nonspecific profile, delete the profile named ABC* and define a profile named AB*. (Before doing this, examine all program names beginning with the characters AB to ensure that this new profile does not authorize unintended access to any additional programs.)

When defining the PROGRAM profile, supply the ADDMEM operand in the following format:

ADDMEM('library_name'/optional_volume_serial/optional_PADCHK_or_NOPADCHK)

For 'library_name', specify the data set name of the library that contains the program, such as 'SYS1.LINKLIB'.

You can optionally specify a volume serial, such as 123456, SYSRES, or VOLAAA. If you specify a volume serial in this format, the PROGRAM profile protects the program only when the specified library exists on that named volume.

If you do not want to specify a specific volume serial, you have two choices:

Omit the volume serial completely. In this case, RACF ignores the volume serial when examining the PROGRAM profile, and considers it a match if the program resides in that library, regardless of the volume serial where the library resides. For this, you could specify:
```
ADDMEM 'SYS1.LINKLIB'//
```
Specify a volume serial of '******' for a special case where the library exists on the IPL volume (not on an extension of the IPL volume, however). For this, you could specify:
```
ADDMEM 'SYS1.LINKLIB/'******'
```

Guideline: In general, specify NOPADCHK to simplify your other setup. Refer to Choosing between the PADCHK and NOPADCHK operands for more information.

For example, a complete ADDMEM specification for a PROGRAM profile might be:

ADDMEM('SYS1.LINKLIB'//NOPADCHK)

A PROGRAM profile can contain multiple ADDMEM operands, such as:

RDEFINE PROGRAM ABC ADDMEM('AAA.LIBRARY1'//NOPADCHK)
RALTER  PROGRAM ABC ADDMEM('BBB.LIBRARY1'//NOPADCHK 'CCC.LIBRARY1'//NOPADCHK)

You can specify a UACC and an access list for your PROGRAM profile, as you would for other profiles. For the purposes of this discussion, remember that you should be using access values of NONE or READ, rather than EXECUTE. See More complex controls: Using EXECUTE access for programs or libraries (BASIC mode) for more information.

Programs reside in program libraries that can be for public use (those in the system link list) or for limited private use (accessed through JOBLIB or STEPLIB, or through the TSO/E CALL command specifying the data set name). To restrict user's ability to run programs, you might need to protect the program library so the user cannot read from it. In some cases you do not need to provide special protection for the program library, other than ensuring that general users cannot update it.

Guideline: Restrict UPDATE access to libraries containing controlled programs, just as you restrict UPDATE access to APF-authorized libraries.

Protecting program libraries discusses the ways to protect the two types of libraries since there might be cases where you need to do this.

When defining your PROGRAM profiles, also consider the following guidelines:

Guidelines:

If the program you are protecting runs APF-authorized or if you specify the program in the conditional access list to use PADS, you generally do not need to prevent the user from reading the library that contains the program. If the user has READ access to the library, he can copy the program to a different library. However, the copy will not execute successfully because it does not come from an APF library and, therefore, will not run with APF authority. Additionally, PADS control will not consider the copy a controlled program.
If the program you are protecting does not run APF-authorized and you do not intend to use it for PADS, you might want to prevent the user from copying it to another library and executing it from there. However, this is probably only important if the program itself contains sensitive data or algorithms. If a program does not contain sensitive data or algorithms, does not run APF-authorized, and is not used for PADS, do not control its use at all. Instead, consider controlling access to the data that the program uses.

You also should consider the following rules when defining your PROGRAM profiles:

Rules:

The profiles protect a program only if it resides in the library specified in the ADDMEM operand.
If you have multiple libraries that contain the program, and the libraries have different data set names, multiple ADDMEM operand specifications are necessary if you want to protect all copies of the program.
You cannot restrict access to programs that reside in the system link pack area (PLPA, MLPA, FLPA, dynamic LPA).
With a multiple-user address space (such as CICS® Transaction Server), if one user loads a program then another user in the same address space can also execute the program while it remains resident.

Restrictions:

Some system functions bypass normal MVS™ contents supervision processing. IMS™ has some functions that operate this way, for example. RACF program control does not work for programs accessed by such functions, because the system invokes the RACF program control functions only when processing a request to LINK, LOAD, XCTL, or ATTACH a program. RACF program control also will not work for programs loaded from z/OS UNIX file systems, but you can still control such programs using UNIX functions such as permission bits and access control lists (ACLs), that work with RACF.
All profiles in the PROGRAM class are discrete profiles. GENERICOWNER is not supported for the PROGRAM class. Even though profiles ending in an asterisk (*) are allowed in this class, they are not generic profiles, but a special form of discrete profile. That's why we use the terms specific and nonspecific when discussing PROGRAM profiles, as we mentioned previously.
WARNING mode is not supported for PROGRAM profiles.
You can specify NOTIFY and auditing for profiles in the PROGRAM class, and for the PROGRAM class itself. However, RACF does not maintain access statistics for PROGRAM profiles.