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.