Skip to main content

By clicking Submit, you agree to the developerWorks terms of use.

The first time you sign into developerWorks, a profile is created for you. Select information in your developerWorks profile is displayed to the public, but you may edit the information at any time. Your first name, last name (unless you choose to hide them), and display name will accompany the content that you post.

All information submitted is secure.

  • Close [x]

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

By clicking Submit, you agree to the developerWorks terms of use.

All information submitted is secure.

  • Close [x]

DB2 10.1 DBA for Linux, UNIX, and Windows certification exam 611 prep, Part 8: Connectivity and networking

Darliene Hopes (, DB2 Solution Migration Consultant, IBM
Darliene Hopes
Darliene Hopes is a DB2 solution migration consultant at IBM. She has been working with DB2 for Linux, UNIX, and Windows since the start of her career. She is an IBM Certified DB2 database administrator who has been recently and consistently contributing to the DB2 community.

Summary:  This tutorial aims to explain the process of configuring communications and the processes of cataloging databases, remote servers (nodes), and Database Connection Services (DCS) databases. You will also get introduced to DB2® Discovery and learn how to manage connections to System z® and System i® host databases. You will also learn about Lightweight Directory Access Protocol (LDAP). This tutorial prepares you for Part 8 of the DB2® 10.1 DBA for Linux®, UNIX®, and Windows® certification exam 611.

View more content in this series

Date:  25 Oct 2012
Level:  Intermediate PDF:  A4 and Letter (389 KB | 20 pages)Get Adobe® Reader®


Configuring communications

Typically, in a client/server environment, databases stored on a server are accessed by remotely stored applications using a distributed connection. The distributed connection also allows administrators to remotely manage databases and servers. Some type of communications protocol recognized by the server must be used in order for this communication with a server to take place. In the same case, each server must use some communications protocol to detect inbound requests from clients. Usually, this is done by using the operating system on each machine to provide the communications protocol support needed. But in some cases, you can use the support provided by a separate add-on product. Either way, clients and servers must be configured to use a communication protocol that is recognized by DB2.

DB2 10 recognizes the following communications protocols:

  • NetBios
  • TCP/IP (this is used in most cases)
  • Named pipe

After installing DB2 on a client or server, it is automatically configured to take advantage of any communications protocols set up for that specific machine if the protocols found are recognized by DB2. Then the information about each of the supported communications protocol available is collected and stored in the configuration files for the DAS instance and the default instance as they are created. Changes in this information, including new protocol activation or the reconfiguring of an existing protocol, must be manually configured for each instance before such changes are reflected as it is not automatically updated.

Manually configuring communications

Using the Setup communications dialog within Data Studio is the simplest way to manually configure communications or make communications configuration changes. An alternate way to configure communications:

  1. Assign the value TCPIP to the DB2COMM registry variable. You must always update the DB2COMM registry variable value before the communications protocol desired can be used. Executing this command sets the registry value to TCPIP: db2set DB2COMM=TCPIP.
  2. Assign the name of the TCP/IP port that the database server will use to receive communications from remote clients to the svcename parameter of DB2 Database Manager configuration file. Executing an UPDATE DATABASE MANAGER CONFIGURATION command will set the parameter. Here is an example of command being set: UPDATE DBM CFG USING SVCENAME db2c_serv1.
  3. Update the services file on the database server, if appropriate. The TCP/IP services file identifies ports where the server applications will listen for requests from clients, so if you specified a service name in the svceneame parameter in the Database Manager configuration file, the correct service name-to-port number/protocol mapping must be added to the services file. If instead a port number was put into the svcename parameter, you do not have to update the services file. Here is an example of an entry in the services file for DB2: db2c_serv1 50001/tcp.

DB2 directory files

DB2 uses directory files to keep track of the locations of the databases on the network. These files also gives the DB2 instances an idea of how to establish connections to those databases with regard to users and applications.

There are four types of directories:

  • System database directory — Contains information, including name and location, for each database cataloged for this instance.
  • Local database directory — Contains information, including name and location, about the databases accessible from that location.
  • Node directory — Contains information that identifies how and where remote systems or instances can be found.
  • Database Connection Services (DCS) directory — Contains information needed to connect to DRDA host databases

2 of 9 | Previous | Next


Zone=Information Management
TutorialTitle=DB2 10.1 DBA for Linux, UNIX, and Windows certification exam 611 prep, Part 8: Connectivity and networking