Consider the following questions:

• Do you have a DNS infrastructure?
  Define name-to-address resolutions in a local hosts file (for example, ETC.IPNODES) or in the appropriate DNS zone files. The following are examples of how to code the resolutions in ETC.IPNODES:

  92.3.1.1             SSCP2A.RALEIGH.COM
  2001:0db8::91:1:1:1  SSCP2AV6.RALEIGH.COM

• Do you use host name support or explicit address coding?
  There are several options for specifying the source VIPA address to be used for a specific EE connection:

  • Use the TCPNAME start option to identify the TCP/IP stack name from which the IPv4 source VIPA address is to be obtained.
  • Use the IPADDR start option to explicitly identify the IPv4 or IPv6 source VIPA address.
  • Use the HOSTNAME start option to identify the host name value to be resolved using name-to-address translation into the correct IPv4 or IPv6 source VIPA address.
  • Use the HOSTNAME or IPADDR parameters on individual GROUP definition statements within the EE XCA major node.
  Guideline: If using the HOSTNAME parameter in a common INET environment, see TCPNAME in z/OS Communications Server: SNA Resource Definition Reference.
  Tip: The HOSTNAME and IPADDR parameters are mutually exclusive. The HOSTNAME parameter value overrides the IPADDR value. See z/OS Communications Server: SNA Resource Definition Reference for details.
  For predefined EE connections, you can specify or obtain the remote IP address of an EE connection in one of the following ways:

  • Specify the IPv4 or IPv6 address of the remote partner on the IPADDR operand on the PATH statement of the switched major node used for EE.
  • Specify the TCP/IP host name of the remote address. This is specified using the HOSTNAME operand of the PATH statement of the switched major node used for EE. The host name can be resolved to an IPv4 or an IPv6 address.

  If you use host name instead of an IP address, you must perform the following additional steps to enable this function:

  1. Configure the resolver.

     VTAM® uses the TCP/IP system resolver to perform name-to-address resolution. The system resolver, in general, first attempts to resolve the name by way of one or more name servers (as defined by resolver configuration statements). If unsuccessful, the resolver then attempts to resolve the name using a local host table, such as HOSTS.SITEINFO (only for IPv4 addresses) or ETC.IPNODES. For more information about defining name servers to the resolver, see z/OS Communications Server: IP Configuration Guide.

     The search order for selecting the TCPIP.DATA file to use is documented in z/OS Communications Server: IP Configuration Guide. VTAM uses the native MVS™ search order. The concept of data set concatenation does not apply here. You may choose to use SYSTCPD for allocating the TCPIP.DATA file. In this case, this statement must be included in your VTAM start procedure.

     If you want to use a local table to resolve host names instead of a name server, see z/OS Communications Server: IP Configuration Guide.

     Note: Enterprise Extender processing uses the native MVS search order for choosing the correct local host table. See z/OS Communications Server: IP Configuration Guide for details on the search order.
  2. Configure the TCPIP.DATA file.
  3. See z/OS Communications Server: IP Configuration Guide for information about UNIX Systems Services security considerations and required security definitions.
  Guidelines:

  • While architecturally able to extend to a maximum of 255 characters, the length of the EE-related HOSTNAME operand is restricted by z/OS® Communications Server to 64 characters. However, the length of the host name you choose to represent the static VIPA should be much shorter than the maximum. The host name is exchanged between APPN nodes in APPN topology and during APPN session setup flows. Those flows carry the host name within APPN control vectors, which are limited to 255 bytes. Calculations using the contents of the APPN Route Selection Control Vector (RSCV) indicate that limiting the fully qualified host name to 40 characters should allow the host name to be exchanged comfortably within reasonably sized APPN networks.
  • If you choose to use the host name function, it is crucial for consistent and predictable EE connection establishment that a given host name resolves to a single IP address. At the TCP/IP stack that owns the host name, the name-to-address resolution should produce the static VIPA address associated with the host name. At a remote EE endpoint wanting to connect to the TCP/IP stack that owns the host name, the name-to-address resolution should produce one of two addresses:
    • If no network address translation is required (for instance, if both nodes are behind the same firewall), the name-to-address resolution at the remote EE partner should generate the static VIPA address of the TCP/IP stack that owns the host name.
    • If network address translation (NAT) is required (for instance, the nodes are separated by a firewall), the name-to-address resolution at the remote EE partner should generate a NAT address. The NAT address is the address that should point to the static VIPA address at the target TCP/IP stack.
  • If you use a name server to resolve host names and your name server runs on a z/OS Communications Server node that uses SOURCEVIPA, code the VIPA address for NSINTERADDR. For more information about SOURCEVIPA, see z/OS Communications Server: IP Configuration Guide.
  • If you use a name server to resolve host names and your name server runs on a z/OS Communications Server node that uses VIPA addresses, but does not use SOURCEVIPA, code a non-VIPA address for NSINTERADDR.
  • If you use a name server to resolve host names and your name server runs on a z/OS Communications Server node that does not use VIPA addresses or if the name server runs on a non-z/OS Communications Server node, there are no additional coding requirements to TCPIP.DATA.