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:
- 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.
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:
- Assign the value
DB2COMMregistry 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:
- 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 CONFIGURATIONcommand will set the parameter. Here is an example of command being set:
UPDATE DBM CFG USING SVCENAME db2c_serv1.
- 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:
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