Connecting Db2 for z/OS distributed database systems with TCP/IP

TCP/IP (which stands for Transmission Control Protocol/Internet Protocol) is a standard communication protocol for network communications. Previous versions of Db2 supported TCP/IP requesters, although additional software and configuration was required.

About this task

Tip: TCP/IP is the recommended communication protocol for communication with Db2. Although SNA communication remains supported in Db2 13, SNA communication (including the VTAM interface) is deprecated, and support might be removed in the future. You can disable SNA communication by setting the value of the DB2 TCP/IP IPNAME setting. See DB2 TCP/IP IPNAME field.

In a TCP/IP network, the domain name (IP address) and port number (service name) uniquely identify a Db2 subsystem. The domain name and the server port number (service name) of the database server must be defined in the communications database (CDB) at a requesting Db2 so that the Db2 subsystem can connect to a remote location. If you use a port number in the CDB to access a remote Db2 location, the port number must be defined to TCP/IP.

The domain name must be defined to the TCP/IP host so that a Db2 subsystem can accept connections from remote locations. Port numbers are never used by a Db2 subsystem that accepts connections. Optionally, you can protect the port number that Db2 uses when acting as a server within TCP/IP from being used by any other task or job in the subsystem. When DDF is started, the Db2 subsystem binds itself to its designed port.

TCP/IP terminology for Db2 for z/OS

The following terms are used for TCP/IP communication in Db2 for z/OS.

IP address
Uniquely identifies a host within the TCP/IP network. This is sometimes called an internet address. A Db2 subsystem resides on a TCP/IP host. The IP address can take two forms. The first form is a 32 bit address that displays in dotted decimal format where X'05041020' displays as 5.4.16.32. The second form is a 128-bit address that displays in colon-hexadecimal format, such as FEDC:BA98:7654:3210:FEDC:BA98:7654:3210.
Domain name
The fully qualified name that identifies an IP address. This can be used instead of the IP address. An example fully qualified domain name is 'stlmvs1.svl.example.com'. Some software refers to stlmvs1 as the hostname and stl.example.com as the domain name. Db2 allows the network administrator to identify a host using a domain name.
Domain name server (DNS)
Manages a distributed directory of domain names and related IP addresses. Domain names can be translated into IP addresses and you can find a domain name associated with a given IP address. Db2 uses the gethostbyname service to get a list of IP addresses for a given domain name.
Port
Identifies an application executing in a host. For example, a port number identifies a Db2 subsystem to TCP/IP. A port number is a two byte integer value that is displayed in decimal format. This number identifies the application within a TCP/IP instance. A port number of X'01D2' displays as 466. There are three basic kinds of TCP/IP ports:
Well-known ports Port numbers in the range 1–1023 that are reserved in the TCP/IP architecture for a specific TCP/IP application. Some typical well-known port numbers are:
  • FTP is port number 21
  • Telnet is port number 23
  • DRDA relational database is port number 446
Ephemeral ports Port numbers that are dynamically assigned to a client process by the client TCP/IP instance. Db2 uses an ephemeral port when it is acting as the DRDA requester. This ephemeral port is associated with the requester for the life of the thread or connection.
Server ports Port numbers that are used when a TCP/IP program does not have a well-known port number, or another instance of the server program is already installed using the well-known port number. As a requester, Db2 defaults to using the DRDA relational database well-known port number to connect to a server location. We suggest that your Db2 subsystem be defined with the DRDA well-known port number of 446. However, the network administrator can assign a server port to the Db2 subsystem. If two different Db2 subsystems reside on the same host, acting as two different locations (a non-data-sharing group), each Db2 subsystem must have a unique port. In this case, only one Db2 subsystem can use the DRDA well-known port number.
Service name
Another way to refer to a port number. A network administrator can assign a service name for a remote location instead of using the port number.
Limitations of TCP/IP communication

TCP/IP does not have the built-in security features that SNA has, such as SNA partner LU verification.

Because IP addresses are not as reliable as LU names, DDF support for TCP/IP differs from support for SNA in these ways:

  • Inbound name translation is not supported.
  • Inbound security requirements cannot be established on individual clients, so the TCPALVER subsystem parameter defines the minimum security requirements for all TCP/IP clients. For more information, see TCP/IP ALREADY VERIFIED field (TCPALVER subsystem parameter).
  • You cannot use the CDB for come from checking of TCP/IP clients.

Procedure

To enable TCP⁄IP communication between DRDA partners and Db2, complete the following steps. You do not have to complete the following steps in exact order, but steps 1–3 should be completed before the other steps.

  1. Prepare the Language Environment® run time library by completing one of the following actions.
    • Concatenate the Language Environment library in the z/OS link list, which does not require the library to be APF-authorized. This is the standard method. If you choose this method, remove the Language Environment library concatenation from the DDF JCL procedure.
    • Include the Language Environment library in a STEPLIB concatenation for the DDF JCL procedure. The Language Environment library must be APF-authorized to be added to the DDF JCL procedure. The Db2 installation automatically adds the library to the DDF STEPLIB concatenation.
  2. Enable DDF for UNIX System Services as described in Enabling Db2 to access TCP/IP services in z/OS UNIX System Services.
  3. Define the Db2 subsystem to TCP⁄IP as described in Db2 configuration with TCP/IP.
  4. Populate the communications database as described in Populating the communications database for use with TCP/IP.
  5. Start TCP⁄IP support by starting DDF. For more information, see Starting TCP/IP support.
  6. Optional: Tune TCP⁄IP to help protect Db2 from outages. Specify a small value for the TCP/IP keep-alive timer. which is specified by the TCPKPALV subsystem parameter. Five minutes or less is best. See TCP/IP KEEPALIVE field (TCPKPALV subsystem parameter).

    If the network fails between the server's reply and the next client request, TCP⁄IP waits until the keep-alive timer expires, then notifies the Db2 subsystem of the failure.

    The server thread hangs while the timer is running. Do not use the timer default of ENABLE because it results in a value of 2 hours, which means that threads can hang for up to 2 hours. A hanging thread can cause unpredictable results, depending on what resources it has locked.

    If you are connecting to a location whose LINKNAME is associated with a row in the table SYSIBM.IPNAMES and it has a domain name in the IPADDR field, gethostbyname can return a list of IP addresses associated with the LINKNAME. When trying to connect to this location, Db2 will try each of these IP addresses in a round-robin fashion (starting with the first address) until the connection is successful, or the attempt to connect to each IP address has timed out.

  7. Specify security requirements for TCP/IP. For more information, see Managing inbound TCP/IP-based connection requests.

What to do next

If you do not plan to communicate with remote sites with SNA/APPC, update the BSDS DDF record with an IPNAME value. The Db2 TCP/IP communications use the IPNAME value and a character representation of the TCP/IP resync port (RESPORT) hexadecimal value to identify units of work. If the BSDS DDF record does not contain an IPNAME value, you must define VTAM® to Db2 because Db2 TCP/IP communications uses the VTAM network ID and LUNAME to identify units of work.

DDF enables TCP/IP communication with partners withDRDA Level 3 support and earlier. Clients must have the updated versions of Db2 Connect or any DRDA requester or server that supports the latest DRDA database protocols. TCP/IP connectivity lets you connect DDF to clients on multiple platforms directly.