Steps for controlling which applications can bind to create a DVIPA

You can define a System Authorization Facility (SAF) resource profile in the SERVAUTH class to control which applications can bind to create dynamic VIPAs (DVIPAs) in a VIPARANGE statement.

Procedure

Perform the following steps to control whether an application can bind to create a DVIPA:

Define the EZB.BINDDVIPARANGE.sysname.tcpname resource profile in the SERVAUTH class. For example, you can define the resource profile using the following RACF® command:
```
RDEFINE SERVAUTH (EZB.BINDDVIPARANGE.sysname.tcpname) UACC(NONE)
```
Give the user ID that is associated with the application READ access to the resource by issuing the following RACF command:
```
PERMIT EZB.BINDDVIPARANGE.sysname.tcpname  ACCESS(READ) CLASS(SERVAUTH) ID(userid)
```
Refresh the profile by issuing the following RACF command:
```
SETROPTS RACLIST(SERVAUTH) REFRESH
```

Results

In this example, sysname is the name of the MVS™ system, userid is the user ID that is associated with the application, and tcpname is the job name of the TCP/IP started task.

The job name for started tasks, such as TCP/IP, is derived depending on how it is started:

If the START command is issued with the name of a member in a cataloged procedure library (for example, S TCPIPX), the job name will be the member name (for example, TCPIPX).
If the member name on the START command is qualified by a started task identifier (for example, S TCPIPX.ABC), the job name will be the started task identifier (for example, ABC). The started task identifier is not visible to all MVS components, but TCP/IP uses it to build the RACF resource name.
The JOBNAME parameter can also be used on the START command to identify the job name (for example, S TCPIPX,JOBNAME=XYZ).
The JOBNAME can also be included on the JOB card.

Results:

If this resource profile is not defined, then the bind is processed.
If this resource profile is defined and the user ID has READ access to the resource, then the bind is processed.
If this resource profile is defined and the user ID does not have READ access to the resource, then the bind fails with a permission denied error, regardless of whether the user is a superuser.