Steps for controlling whether an application can issue a SIOCSVIPA ioctl call or call the MODDVIPA utility to create a DVIPA within a specific VIPARANGE subnet

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

Procedure

Perform the following steps to protect a specific VIPARANGE subnet so that only a particular application can issue a SIOCSVIPA ioctl call or call the MODDVIPA utility to create a DVIPA in the protected range.

Define the EZB.MODDVIPA.sysname.tcpname.resname resource profile in the SERVAUTH class. For example, to protect a VIPARANGE subnet for application APPL1, you can define the EZB.MODDVIPA.sysname.tcpname.APPL1 resource profile using the following command:
```
RDEFINE SERVAUTH (EZB.MODDVIPA.sysname.tcpname.APPL1) UACC(NONE)
```
On the VIPARANGE statement, include the SAF parameter with a resname value that matches the resname value on the EZB.MODDVIPA.sysname.tcpname.resname resource profile. For example:
```
VIPARANGE DEFINE 255.255.255.255 10.10.10.1 SAF APPL1
```
For more information about the SAF parameter on the VIPARANGE statement, see z/OS Communications Server: IP Configuration Reference.
Give the user ID that is associated with the application READ access to the EZB.MODDVIPA.sysname.tcpname.resname resource. For example:
```
PERMIT EZB.MODDVIPA.sysname.tcpname.APPL1 ACCESS(READ) CLASS(SERVAUTH) ID(userid)
```
Refresh the resource 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. For information about how the job name for a started task, such as TCP/IP, is determined, see Steps for controlling which applications can issue a SIOCSVIPA ioctl call or call the MODDVIPA utility to create a DVIPA.

Results:

If the SAF parameter is specified and the user ID has READ access to the resource, then the call is processed.
If the SAF parameter is specified and the user ID does not have READ access to the resource, then the call fails.
If the SAF parameter is specified but the resource profile is not defined, then the call fails.
All of the following profile specifications that include wildcard values match the EZB.MODDVIPA.sysname.tcpname.resname resource profile name:
- EZB.MODDVIPA.*.*
- EZB.MODDVIPA.**
- EZB.MODDVIPA.*.*.*
The most specific match to a resource profile name is always used. For example, consider the following VIPARANGE definitions:
```
VIPARANGE DEFINE 255.255.255.0 10.10.10.1
VIPARANGE DEFINE 255.255.255.255 10.10.10.210 SAF APPL1
VIPARANGE DEFINE 255.255.255.255 10.10.10.211 SAF APPL2
```
If moddvipa -p TCPCS -c 10.10.10.20 is issued, then the first VIPARANGE statement matches and EZB.MODDVIPA.sysname.tcpname is used.

If moddvipa -p TCPCS -c 10.10.10.210 is issued, although the first VIPARANGE statement matches, the most specific VIPARANGE statement match from these sample statements is the second statement, so the EZB.MODDVIPA.sysname.tcpname.APPL1 resource is used.

Rule: If this resource profile is defined and you want to delete a DVIPA that was created using the SIOCSVIPA ioctl call, the SIOCSVIPA6 ioctl call, or the MODDVIPA utility, the user ID must have READ access to the resource that was used to create the DVIPA.