Different application uses of IP addresses and DVIPAs

Not all IP-based server applications relate to IP addresses in the same way. Automated movement of DVIPAs, and the planning for dynamic VIPA takeover, must take this difference into account.

Some IPv4 or IPv6 applications, such as FTP or the TN3270E Telnet server (Telnet) will accept client requests on any IP address by binding to INADDR_ANY or the IPv6 unspecified address (in6addr_any). The distinguishing feature of such an application is the function it provides, such as the particular set of SNA applications for Telnet. If the function is replicated across multiple z/OS® images in the sysplex, as is often the case for distributed workload, the DVIPA must merely be moved to a stack supporting the application. This scenario is called the multiple application-instance scenario. For the multiple application-instance scenario, the stacks in the sysplex do all the work of activating a DVIPA in the event of a failure.

For other types of applications, each application instance must have a unique IP address. This scenario is called the unique application-instance scenario and uses DVIPAs that are activated with an ioctl or a bind().

To maintain the relationship between an application instance and its DVIPA, the application must indicate to the stack that the DVIPA needs to be activated. This occurs in the following cases:

When the application instance issues a bind() function call and specifies an IP address that is not active on the stack. The stack will activate the address as a DVIPA, provided it meets certain criteria. When the application instance closes the socket, the DVIPA is deleted.
Some applications cannot be configured to issue bind() for a specific IP address, but are unique application-instance scenario applications. For such applications, a utility is provided (MODDVIPA), which issues SIOCSVIPA or SIOCSVIPA6 ioctl() to activate or deactivate the DVIPA. This utility can be included in a JCL procedure or OMVS script to activate the DVIPA before initiating the application. As long as the same JCL package or script is used to restart the application instance on another node in the event of a failure, the same DVIPA will be activated on the new stack. For information about the authorization required to execute the MODDVIPA utility, see Using the MODDVIPA utility.
An alternative for unique application-instance scenario server applications that cannot themselves bind to a unique IP address is to use the BIND parameter on the PORT reservation statement. It is always a good practice to reserve a port for the listening socket of a server application. If the BIND parameter and an IP address are specified on the PORT reservation statement for a server application, and the application binds a socket to that port and either the IPv4 INADDR_ANY address or the IPv6 unspecified address (in6addr_any), z/OS TCP/IP will convert the bind to be specific to the IP address specified on the PORT reservation statement. From that point on, it will appear as though the application itself had issued the bind() specifying the designated IP address, including having the IP address deleted when the server application closes the socket.