Supported methods for specifying DVIPAs

Db2 for z/OS® supports two methods for specifying DVIPAs: the BSDS (INADDR_ANY) method and the BINDSPECIFIC method; however, only one method might be viable for your particular environment.

Important: These methods are mutually exclusive. Use only one of the following methods to specify DVIPAs: BSDS (INADDR_ANY) method or the BINDSPECIFIC method to specify DVIPAs. Use the information in this topic to determine which method is appropriate for your environment.

Which method should you choose?

The preferred method for specifying DVIPAs is the BSDS (INADDR_ANY) method. This method provides greater flexibility with handling network addressing changes without impacting your applications. However, there are certain situations and restrictions that require to use one method instead of the other.

  • You must use the BINDSPECIFIC method if within your TCP/IP configuration a DDVIPA is configured with no port values specified in its definition so that it can be shared by many applications, and all of those applications bind their ports to this DDVIPA. In this type of configuration, in which the DDVIPA dynamically learns the ports it is to manage, the DDVIPA cannot be used exclusively as the Db2 group IP address in its BSDS as the GRPIPV4 address or GRPIPV6 address.
  • You must use the BSDS (INADDR_ANY) method if you're using IBM® Db2 Analytics Accelerator.

Overview of the BSDS (INADDR_ANY) configuration

With the BSDS (INADDR_ANY) method, you specify DVIPAs in the bootstrap data set that use by using the DSNJU003 utility.

The following figure shows an example BSDS (INADDR_ANY) configuration for setting up a three-member data sharing group. In this example:
  • Vx represents the group DVIPA, and V1, V2, and V3 represent the members' DVIPAs.
  • The group DVIPA and the member-specific DVIPAs are defined on each TCP/IP stack.
  • The SHAREPORT option is required only when multiple members are started on the same LPAR or TCP/IP stack. Without this option, TCP/IP does not allow multiple listeners on the DRDA port.
  • The VIPADYNAMIC statements are structured as follows:
    • The group DVIPA must be defined with the VIPADEFINE and VIPADISTRIBUTE statements on one of the TCP/IP stacks within the sysplex, and the system where the definition is activated will be considered the primary system of the sysplex distributor.
    • The group DVIPA can also be defined with the VIPABACKUP statement on the TCP/IP stacks for DVIPA takeover. Note that the VIPABACKUP statements are coded with the MOVEABLE IMMEDIATE keywords, and that the VIPADISTRIBUTE statements are also specified on the backup TCP/IP stacks. This allows for the group DVIPA to be activated on one of the backup stacks if it is not active anywhere else in the Sysplex. For example, if z/OS-1 has not been started when z/OS-2 or z/OS-3 starts, then group DVIPA is activated on one of the backup stacks.
    • To allow for failover, the member-specific DVIPAs are defined with the VIPARANGE statement on all TCP/IP stacks.
Figure 1. Example TCP/IP network configuration (INADDR_ANY IPv6 dynamic virtual IP addressing)
Begin figure description. A three-member data sharing group routes DVIPA requests and performs workload balancing as described by the surrounding text. End figure description.
  1. The initial connection uses the group dynamic Virtual IP Addresses (Vx). Port 446 is identified as the DRDA port in each member's PORT statements.
  2. The sysplex distributor dispatches the initial connection request to the member with the lightest workload (DB2B).
  3. Resynchronization information and a list of members in the data sharing group are returned to the requester.
  4. Database-level workload balancing connections are established.

See Configuring TCP/IP group access by using the BSDS (INADDR_ANY) method for instructions.

Overview of the BINDSPECIFIC configuration

In a BINDSPECIFIC configuration, you specify DVIPAs on the PORT statement of the TCP/IP profile by using the BIND keyword. A Db2 data sharing group member accepts connection requests only if the IP address that is used to target the member is either the member DVIPA (IPv4 or IPv6, but not both), or the group DVIPA (IPv4 or IPv6).

The following figure shows an example BINDSPECIFIC configuration for setting up a three-member data sharing group to route DVIPA requests and perform workload balancing across the members. In this example:
  • Vx represents the group DVIPA, and V1, V2, and V3 represent the members' DVIPAs.
  • The group DVIPA and the member-specific DVIPAs are defined on each TCP/IP stack.
  • The SHAREPORT option is required only when multiple members are started on the same LPAR or TCP/IP stack; without this option, TCP/IP does not allow multiple listeners on the DRDA port.
  • The BIND (SPECIFIC) option restricts the clients to use only the group DVIPA or member DVIPA to connect to Db2.
  • The VIPADYNAMIC statements are structured as follows:
    • The group DVIPA must be defined with the VIPADEFINE and VIPADISTRIBUTE statements on one of the TCP/IP stacks within the sysplex. The system where the definition is activated is considered the primary system of the sysplex Distributor.
    • The group DVIPA must be defined with the VIPABACKUP statement on the TCP/IP stacks for DVIPA takeover. Note that the VIPABACKUP statements are coded with the MOVEABLE IMMEDIATE keywords, and that the VIPADISTRIBUTE statements are also specified on the backup TCP/IP stacks. These statements allow for the group DVIPA to be activated on one of the backup stacks if it is not active anywhere else in the Sysplex. For example, if z/OS-1 has not been started when z/OS-2 or z/OS-3 launch, then group DVIPA is activated on one of the backup stacks.
    • To allow for failover, the member-specific DVIPAs are defined with the VIPARANGE statement on all TCP/IP stacks.
Figure 2. Example TCP/IP network configuration (BINDSPECIFIC IPv6 dynamic virtual IP addressing)
Begin figure description. A three-member data sharing group routes DVIPA requests and performs workload balancing as described by the surrounding text. End figure description.
  1. The initial connection uses the group dynamic virtual IP addresses (Vx). Port 446 is identified as the DRDA port in each member's PORT statements.
  2. The sysplex distributor dispatches the initial connection request to the member with the lightest workload (DB2B).
  3. Resynchronization information and a list of members in the data sharing group are returned to the requester.
  4. Database-level workload balancing connections are established.

See Configuring TCP/IP group access by using the BINDSPECIFIC method for instructions.