Steps for controlling which applications can issue a SIOCSVIPA ioctl call or call the MODDVIPA utility to create a DVIPA

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

Procedure

Perform the following steps to control whether an application can issue a SIOCSVIPA ioctl call or call the MODDVIPA utility to create a DVIPA:

Define the EZB.MODDVIPA.sysname.tcpname resource profile in the SERVAUTH class by issuing the following RACF® command:
```
RDEFINE SERVAUTH (EZB.MODDVIPA.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.MODDVIPA.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, tcpname is the job name of the TCP/IP started task, and userid is the user ID that is associated with the application. 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 defined and the user ID has READ access to the resource, then the call is processed.
If this resource profile is not defined and the user ID is not APF authorized and is not a UNIX System Services superuser, the call fails.
If this resource profile is defined and the user ID does not have READ access to the resource, then the call fails with a permission denied error, regardless of whether the user is a superuser.

Rules:

If specific and wildcard resource profile names are defined, the user ID must have READ access to the resource that has the most specific match. For example, defining EZB.MODDVIPA.MVS1.TCPCS1 and EZB.MODDVIPA.MVS1.* has the following results:
- To create a DVIPA on system MVS1, TCP/IP stack TCPCS1, the user ID must have READ access to EZB.MODDVIPA.MVS1.TCPCS1.
- To create a DVIPA on system MVS1, TCP/IP stack TCPCS2, the user ID must have READ access to EZB.MODDVIPA.MVS1.*.
- If a user ID tries to create a DVIPA on a TCP/IP stack on system MVS2, there is no matching resource profile.
If this resource profile is defined, the user ID must also have READ access to the resource to delete a DVIPA that was created using the SIOCSVIPA ioctl call, the SIOCSVIPA6 ioctl call, or the MODDVIPA utility.