Installing and Configuring DB2 Clients
This section assumes that TCP/IP is functional on the client and DB2
server workstations. See "Software Requirements" for the communication protocol requirements for your platform. See "Possible Client-to-DB2 Server Connectivity Scenarios" for the supported communication protocols for your particular client and
server.
The following steps are required to set up a DB2 client to use TCP/IP
communications:
- Identify and record parameter values.
- Configure the client:
- Resolve the server's host address.
- Update the services file.
- Catalog the TCP/IP node.
- Catalog the database.
- Test the connection between the client and server.
|
Due to the characteristics of the TCP/IP protocol, the TCP/IP subsystem may
not be immediately notified of the failure of a partner on another
host. As a result, a client application accessing a remote DB2 server
using TCP/IP, or the corresponding agent at the server, may sometimes appear
to be hung. DB2 uses the TCP/IP SO_KEEPALIVE socket option to detect
when there has been a failure and the TCP/IP connection has been
broken.
If you are experiencing problems with your TCP/IP connection, refer to the
Troubleshooting Guide for information on this parameter and other common TCP/IP problems.
|
As you proceed through the configuration steps, complete the
Your Value column in the following table. You can fill in
some of the values before you start configuring this protocol.
Table 11. TCP/IP Values Required at the Client
| Parameter
| Description
| Sample Value
| Your Value
|
| Hostname (hostname)
or
IP address (ip_address)
|
Use the hostname or ip_address of the remote server
workstation.
To resolve this parameter:
- Issue the hostname command at the server to obtain the
hostname parameter.
- Issue the ping server_hostname command to obtain the
ip_address parameter.
| serverhost
or
9.21.15.235
|
|
|
Connection Port
- Connection Service name (svcename)
- Port number/Protocol (Port_number/tcp)
|
Values required in the services file.
The Connection Service name is an arbitrary name used to represent the Port
number (Port_number) on the client.
The Port number for the client must be the same as the Port number that the
svcename parameter maps to in the services file at the server.
(The svcename parameter is located in the database manager
configuration file on the server.) This value must not be in use by
another application and must be unique within the services file.
Contact your LAN administrator for the values used to configure the
server.
|
server1
3700/tcp
|
|
| Node name (Node_name)
|
A local alias, or nickname, that describes the node where the database
resides. You can choose any name you want, however, all Node name
values within your local node directory must be unique.
| db2node
|
|
The following steps describe how to configure this protocol
on the client. Replace the sample values with your worksheet
values.
|
If your network has a name server, or you are planning to directly specify
the IP address (ip_address) of the server, skip this step and proceed
to "Step B. Update the Services File".
|
The client workstation must know the address of the server to which it is
attempting to establish communications. If a name server does not exist
on your network, you may directly specify a hostname that maps to the IP
address (ip_address) of the host in the local hosts file. See Table 12 for the location of the hosts file for your particular
platform.
| If you are planning on supporting a UNIX client that is using Network
Information Services (NIS), and you are not using a name server on your
network, you must update the hosts file located on your NIS master
server.
|
Table 12. Location of the Local Hosts and Services Files
| Platform
| Location
|
| Macintosh
|
The hosts file is located in the folder called System
Folder.
| Note: | This operating system does not use a services file. You must catalog
this node using the Port_number parameter. See "Step C. Catalog the TCP/IP Node" for more information.
|
|
| OS/2
| Specified by the etc environment variable.
Issue the set etc command to determine the location of your
local hosts or services files.
| Note: | For DOS and WIN-OS2 sessions, you might need to update the hosts and services
files located in the tcpip_product\dos\etc directory.
|
|
| Windows 3.x
| Typically in the tcpip_product\etc directory, but it depends on the
products that you have installed.
Refer to your TCP/IP documentation for more information.
|
| Windows 95
| windows directory
|
| Windows NT
| winnt\system32\drivers\etc directory
|
| UNIX
| /etc directory
|
Using a local text editor, add an entry to the client's hosts file for
the server's hostname. For example:
9.21.15.235 serverhost # host address for serverhost
where:
- 9.21.15.235
- is the ip_address
- serverhost
- is the hostname
- #
- is a comment describing the entry
Notes:
- If the server is not in the same domain as the client, you must provide a
fully specified domain name such as
serverhost.vnet.ibm.com, where
vnet.ibm.com is the domain name.
- For specific information on resolving host addresses, refer to your
TCP/IP documentation.
Using a local text editor, add the Connection Service name and Port number
to the client's services file for TCP/IP support. For
example:
server1 3700/tcp # DB2 connection service port
where:
- server1
- is the Connection Service name
- 3700
- is the Port number for the Connection Port
- tcp
- is the communication protocol that you are using
The Port number used on the client must match the Port number used on the
server.
|
If you are planning on supporting a UNIX client that is using Network
Information Services (NIS), you must update the services file located on your
NIS master server.
The file called services is located in the same directory as the local
hosts file that you may have edited in "Step A. Resolve the DB2 Server's Host Address".
See Table 12 for the location of the services file for your particular platform.
|
You must add an entry to the client's node directory
to describe the remote node.
This entry specifies the chosen alias (Node_name), the
hostname (or ip_address), and the svcename (or
Port_number) that are to be used to access the remote server.
To catalog the TCP/IP node, perform the following steps:
- Log on to the system as a user with System Administrative (SYSADM) or
System Controller (SYSCTRL) authority.
- If you are using UNIX, set up the instance environment and invoke the DB2
command line processor as follows:
- Run db2profile or db2cshrc as follows:
. INSTHOME/sqllib/db2profile (for Bourne or Korn shell)
source INSTHOME/sqllib/db2cshrc (for C shell)
where INSTHOME is the home directory of the instance
- Start the DB2 command line processor by issuing the db2
command.
- Catalog the node by issuing the following commands in the command line
processor:
catalog tcpip node Node_name remote [ hostname | ip_address ] server [ svcename | Port_number ]
terminate
For example, to catalog the remote server serverhost on the node
called db2node, using the service name server1, use:
catalog tcpip node db2node remote serverhost server server1
terminate
To catalog a remote server with the IP address
9.21.15.235 on the node called db2node,
using the Port number 3700, use:
catalog tcpip node db2node remote 9.21.15.235 server 3700
terminate
|
If you need to change values that were set with the catalog node
command, first run the uncatalog node command in the command line
processor as follows:
uncatalog node Node_name
Recatalog the node with the value that you want to use.
|
Before a client application can access a remote database, the database must
be cataloged on the server node and on any client nodes that will connect to
it. When you create a database, it is automatically cataloged on the
server with the Database alias (Database_alias) the same as the Database name
(Database_name). The information in the database directory, along with
the information in the node directory, is used on the client to establish a
connection to the remote database.
To catalog a database on the client, perform the following steps.
- Log on to the system as a user with System Administrative (SYSADM) or
System Controller (SYSCTRL) authority.
- Fill in the Your Value column in the following
worksheet.
Table 13. Parameter Values for Cataloging Databases
| Parameter
| Description
| Sample Value
| Your Value
|
| Database name (Database_name)
| The Database alias (Database_alias) of the remote
database. When you create a database, it is automatically cataloged on
the server with the Database alias name (Database_alias) the same as the
Database name (Database_name).
| sample
|
|
| Database alias (Database_alias)
| An arbitrary local nickname for the remote database, on the
client. If you do not provide one, the default is the same as the
Database name (Database_name). This is the name that you use
when connecting to a database from a client.
| tor1
|
|
| Node name (Node_name)
| The name of the node directory entry that describes where the database
resides. Use the same value for Node name (Node_name) that you
used to catalog the node in the previous step.
| db2node
|
|
- If you are using UNIX, set up the instance environment and invoke the DB2
command line processor as follows:
- Run db2profile or db2cshrc as follows:
. INSTHOME/sqllib/db2profile (for Bourne or Korn shell)
source INSTHOME/sqllib/db2cshrc (for C shell)
where INSTHOME is the home directory of the instance
- Start the DB2 command line processor by issuing the db2
command.
- Catalog the database by issuing the following commands in the command line
processor:
catalog database Database_name as Database_alias at node Node_name
terminate
For example, to catalog a remote database called sample so that
it has the alias tor1, on the node db2node, use:
catalog database sample as tor1 at node db2node
terminate
|
If you need to change values that were set with the catalog
database command, first run the uncatalog
database command in the command line processor as
follows:
uncatalog database Database_alias
Recatalog the database with the value that you want to use.
|
When the configuration of the client is complete, use the
following steps to verify that you can access data from a remote
database:
|
You will need to connect to a remote database to test the
connection. If you do not have a database on the server, create the
sample database on the server to test the connection. Refer to the Quick Beginnings manual for more information.
|
- Start the database manager by issuing the db2start command on
the server (if it was not automatically started at boot time).
- Issue the following command in the client's Command Center or command
line processor to connect the client to the remote database:
connect to Database_alias user userid using password
The values for userid and password must be valid for the
system on which they are authenticated. By default, authentication
takes place on the SERVER. If the database manager is configured for
CLIENT authentication, the userid and password must be valid
on the client.
If the connection is successful, you will get a message showing the name of
the database to which you have connected. You are now able to retrieve
data from that database. For example, to retrieve a list of all the
table names listed in the system catalog table, enter the following SQL
command in the Command Center or command line processor:
"select tabname from syscat.tables" (for UNIX-based platforms)
select tabname from syscat.tables (for other platforms)
When you are finished using the database connection, issue the connect
reset command to end the database connection.
If the connection fails, check the following items:
At the server:
- The DB2COMM registry parameter includes the value
tcpip.
- The services file was updated correctly.
- The Service name (svcename) parameter was updated correctly in
the database manager configuration file.
- The security service was started (issue the net start
db2ntsecserver command-for Windows NT servers only).
- The database was created and cataloged properly.
- The database manager was stopped and started (issue the db2stop
and db2start commands on the server).
|
If there are problems starting a protocol's connection managers, a
warning message is displayed and the error messages are logged in the
db2diag.log file. The location of this file depends on your
operating system.
- UNIX-based Platforms
- $HOME/sqllib/db2dump directory, where $HOME is home directory of
the instance owner.
- Other Platforms
- x:\sqllib\%db2instance% directory, where x: is the
drive that the client is installed and %db2instance% represents the
DB2 instance.
Refer to the Troubleshooting Guide for information on the db2diag.log file.
|
At the client:
- If used, the services and hosts files were updated correctly.
- The node was cataloged with the correct Hostname (hostname) or IP
address (ip_address).
- The Port number must match, or map to, the Port number used on the
server.
- The Node name (Node_name), specified in the database directory,
points to the correct entry in the node directory.
- The database was cataloged properly, using the server's
Database alias (Database_alias) that was cataloged when the database
was created on the server, as the Database name (Database_name) on
the client.
After you verify these items, refer to the Troubleshooting Guide if the connection still fails.
[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]
[ DB2 List of Books |
Search the DB2 Books ]