IBM data server clients and drivers overview > Installation methods for IBM data server clients > Database connections for IBM data server clients >
Client-to-server communications configuration overview
This topic provides information for choosing a suitable method
for configuring client-to-server communications. This topic applies
to configuring IBM® data
server client and
server products rather than to database connectivity drivers.
Understanding client-to-server communications: Components
and scenarios
The basic components involved in client-to-server
communications are described below:
- Client. This refers to the initiator of the communications.
This role can be filled by any of the following DB2® products
or components:
- IBM Data
Server Driver Package
- IBM Data Server Client or IBM Data Server Runtime Client.
- DB2® Connect™ Personal Edition:
This product is a superset of the IBM Data Server Client.
- a DB2 server product: A DB2 server
is a superset of the Data Server Client.
- Server. This refers to the receiver of the communications
request from the client. This role is normally filled by a DB2 for Linux®, UNIX®,
and Windows® server product. When DB2
Connect products are present, the term server can also
mean a DB2 server on a midrange or mainframe platform.
- Communications protocol. This refers to the protocol used
to send data between the client and server. The DB2 product
supports several protocols:
- TCP/IP. A further distinction can be made between the version:
TCP/IPv4 or TCP/IPv6.
- Named Pipes. This option is available on Windows only.
- IPC (interprocess communications). This protocol is used for local
connections.
There are also some additional components encountered in
some environments:
- DB2 Connect gateway. This refers
to a DB2 Connect Server product that provides
a gateway by which IBM data
server client can
connect to DB2 servers on midrange and mainframe products.
- LDAP (Lightweight Directory Access Protocol). In an LDAP-enabled
environment, it is not necessary to configure client-to-server communications.
When a client attempts to connect to a database, if the database does
not exist in the database directory on the local machine then the
LDAP directory is searched for information required to connect to
the database.
The scenarios listed below illustrate examples of situations
covered by client-to-server communications:
- Data Server Client establishes
communications with a DB2 server using TCP/IP.
- Data Server Runtime Client establishes
communications with a DB2 server using Named Pipes on
a Windows network.
- DB2 server establishes communications with another DB2 server
via some communications protocol.
- Data Server Client establishes
communications with a mainframe DB2 server
via a DB2 Connect server using TCP/IP.
When setting up a
server to work with development environments (such as IBM Data
Studio), you might encounter error message SQL30081N at the initial DB2 connection.
A possible root cause is that the firewall at the remote database
server has prevented the connection from being established. In this
case, verify the firewall is properly configured to accept connection
requests from the client.
Understanding client-to-server communications: Types
of connections
Generally speaking, references to setting
up client-to-server communications refer to remote connections,
rather than local connections.
A local connection is
a connection between a database manager instance and a database managed
by that instance. In other words, the CONNECT statement is issued
from the database manager instance to itself. Local connections are
distinctive because no communications setup is required and IPC (interprocess
communications) is used.
A remote connection is one
where the client issuing the CONNECT statement to a database is in
a different location from the database server. Commonly, the client
and server are on different machines. However, remote connections
are possible within the same machine if the client and server are
in different instances.
Another less common type of connection
is a loopback connection. This is a type of remote connection
where the connection is configured from a DB2 instance
(the client) to the same DB2 instance (the server).
Comparison of methods for configuring client-to-server
communications
Several methods are available for configuring
client-to-server communications. Choosing a suitable method involves
answering two questions. The first is Which tool will you use:
Configuration Assistant or command line tools?
- The Configuration Assistant is a graphical tool provided with
versions of the Data Server Client and DB2 server
products on Windows and Linux on
Intel™ x86 32-bit platforms and AMD64/EM46T platforms. This tool is
not provided with the Data Server Runtime Client.
- The command line tools consist of the Command Line Processor (CLP),
and the commands db2cfexp (configuration export),
and db2cfimp (configuration import).
The second question is: What type of configuration task
do you want to perform? Options are:
- Configure a client by entering information manually.
- Configure a client by searching the network for servers to connect
to.
- Make databases on a server accessible to one or more clients.
- Use the connection settings for one client as the basis for configuring
additional clients.
With answers to these questions, you can use the table below
to identify the appropriate configuration method. Links to each method
are provided at the end of this topic. Notes follow the table that
provide more details.
Table 19. Tools and methods for configuring a client-to-server connection
| Type of configuration task |
Configuration Assistant |
Command line |
| Configure a client by entering information manually |
Configure a database connection manually with
the Configuration Assistant |
Configure client-to-server connections using
the command line processor |
| Configure a client by searching the network
for servers to connect to |
Configure a database connection by searching
the network with the Configuration Assistant |
Not applicable |
| Use the connection settings for one client as
the basis for configuring additional clients |
- Create a client profile using the Configuration Assistant
- Configure database connections using a client profile with the
Configuration Assistant
|
create and use a client profile using commands db2cfexp and db2cfimp |
Note:
Profiles are used in some methods for configuring
client-to-server communications. A
client profile is a file
that contains settings for a client. Settings can include:
- Database connection information (including CLI or ODBC settings).
- Client settings (including database manager configuration parameters
and DB2 registry variables).
- CLI or ODBC common parameters.
A
server profile is similar to a client profile but contains
settings for a server. Profiles can be created and used with the Configuration
Assistant or by using the commands db2cfexp (configuration
export), and db2cfimp (configuration import).
Note:
Configuring a database connection by searching the
network with the Configuration Assistant is not a recommended method
for DB2 Connect customers connecting to databases
on midrange or mainframe platforms.
Supported combinations of client and server versions
This section describes which versions of a client can connect
to which versions of a server. This includes support for earlier versions
and support for accessing DB2 databases
on midrange and mainframe servers.
Combinations of DB2® Universal Database™ (UDB)
Version 8, DB2 Version 9.1,
and DB2 Version 9.5 (and higher)
DB2 Universal Database (UDB)
Version 8 and DB2 Version 9.1
clients can access a remote DB2 Version
9.5 server.
Note the following restriction:
- There is a restriction when a client is located on the same system
as a DB2 server, and they are
different versions. In this case, local client-to-server connections
using Interprocess Communication (IPC) are not supported. Instead,
a connection can be established by treating the connection as a remote
connection (called a loopback connection) using TCP/IP.
IBM Data Server Client, IBM Data Server Runtime Client,
and IBM Data
Server Driver Package Version
9.5 can
access DB2 Version 9.1 and DB2 UDB Version 8 servers. However,
new DB2 Version 9.5 functionality
is not available.
Access
to DB2 Version 9.5 (and higher) servers from DB2 UDB Version 7 clients
Access from DB2 UDB Version 7 clients is not
supported.
Combinations
of DB2 Version 9.5 (and higher) and DB2 products
on midrange and mainframe platforms
DB2 Version
9.5 servers support
access from the following clients on midrange and mainframe
platforms:
- DB2 for z/OS® and OS/390® Version
7 or later
- DB2 for i5/OS® Version 5 or later
- DB2 for VM and VSE Version
7
IBM Data Server Client Version
9.5, IBM Data Server Runtime Client Version
9.5,
and DB2 Version 9.1 clients
can access DB2 Connect Version
9.5,
Version 9.1, and Version 8.
Communication protocols supported
This topic identifies the supported protocols for connecting
from an IBM data
server client to
a DB2 server. This includes:
- connecting from IBM data
server client to
midrange or mainframe hosts using DB2
Connect products.
- connecting from mid range or mainframe platforms to databases
on DB2 for Linux, UNIX,
and Windows.
The TCP/IP protocol is supported on all platforms on which DB2 for Linux, UNIX,
and Windows is available. Both TCP/IPv4 and TCP/IPv6
are supported. IPv4 addresses have a four-part structure, for example, 9.11.22.314. IPv6
addresses have an eight-part name, where each part consists of 4 hex
digits delimited by a colon. Two colons (::) represents one or more
sets of zeros. For example, 2001:0db8:4545:2::09ff:fef7:62dc.
DB2 database
products support the SSL protocol and accept SSL requests from applications
that use the IBM Data Server Driver for JDBC
and SQLJ (type
4 connectivity), IBM Data
Server Driver for ODBC and CLI and IBM Data
Server Driver Package. Refer to Configuring
Secure Sockets Layer (SSL) support in a DB2 instance.
In
addition, the Windows Named Pipes protocol
is supported on Windows networks. To administer
a DB2 database remotely, you must connect using
TCP/IP.
Adding database connections using the Configuration Assistant
Configuring client-to-server connections using the Configuration
Assistant (CA)
The Configuration Assistant is a graphical tool that can
be used to configure database connections between a client and a remote DB2 database.
Important:
The Configuration
Assistant has been deprecated in Version 9.7 and might be removed
in a future release. For more information,
see the "Control Center tools and DB2 administration server (DAS)
have been deprecated" topic in the What's New in Version 9.7 book.
The Configuration Assistant is provided with the IBM Data Server Client and DB2 database
products on Windows and Linux (Intel® x86
and x64 platforms).
The Configuration Assistant can configure a connection to a database
only if the remote database manager is configured to accept inbound
client requests. By default, the DB2 database
product installation program detects and configures most protocols
for inbound client connections.
You can configure a connection to a database using one of the following
methods:
- Configuring a database connection by searching the network
using the Configuration Assistant
- Use this method if you don't have any information about the database
you want to connect to. This method will search your network and list
all the databases available to you. A DB2 Administration
Server (DAS) must be running and enabled on the servers for the discovery
feature of the CA to return information about DB2 systems.
- Configuring database connections using a client profile with the Configuration
Assistant
- Use this method if you have been given a file that contains all
the necessary information to access the target database. This method
can also be used to catalog and connect to multiple databases specified
in the access profile file.
- Configuring a database connection manually using the Configuration
Assistant
- Use this method if you know all the information necessary to connect
to the target database. You must know:
- The communication protocols supported by the server on which the
target database resides
- The appropriate communication parameters for the server's protocols
- The name of the database
Configuring a database connection manually using the Configuration
Assistant
If you have the information for the database you want
to connect to and the server upon which it resides, you can manually
enter all of the configuration information. This method is analogous
to entering commands using the command line processor, however, the
parameters are presented graphically.
Before you configure a connection to a database manually
using the Configuration Assistant (CA):
- Ensure that you have a valid DB2 user
ID for the database you want to connect to.
- If you are configuring a connection from a system that has a DB2 server
or DB2 Connect server product installed,
ensure that you have a user ID with SYSADM or SYSCTRL authority for
the database manager instance.
To configure a connection to a database manually using the
CA:
- Log on to the system with a valid DB2 user
ID.
- Start the CA. The CA can be started from the Start menu
on Windows or using the db2ca command.
- On the CA menu bar, under Selected,
choose Add Database Using Wizard.
- Select the Manually configure a connection to
a database radio button and click Next.
- If you are using Lightweight Directory Access Protocol
(LDAP), select the radio button that corresponds to the location where
you want DB2 directories to be maintained. Click Next.
- Select the radio button that corresponds to the protocol
that you want to use from the Protocol list.
(Note: While APPC, APPN, or NetBIOS might still display as options,
they are no longer supported.) If DB2
Connect is installed on your system and you select TCP/IP, you
have the option to select The database physically resides
on a host or OS/400 system. If you select this check box,
you have the option of selecting the type of connection that you want
to make to the host or OS/400® database:
- To make a connection through a DB2
Connect gateway, select the Connect to the server
via the gateway radio button.
- To make a direct connection, select the Connect directly
to the server radio button.
Click Next.
- Type the required communication protocol parameters and
click Next.
- Type the database alias name of the remote database that
you want to add in the Database name field
and a local database alias name in the Database alias field.
If you are adding a host or OS/400 database,
type the location name for an OS/390 or z/OS database,
the RDB name for an OS/400 database, or the DBNAME
for a VSE or VM database in the Database name field.
Optionally, you can add a comment that describes this database in
the Comment.
Click Next.
- If you are planning to use ODBC, register this database
as an ODBC data source. Ensure that ODBC is installed before performing
this operation. Click Next.
- In the Specify the node options window,
select the operating system, and type the remote instance name for
the database system you want to connect to.
- In the Specify the system options window,
ensure that system name, host name, and operating system are correct.
The information on this panel is used to configure the administration
node. You can optionally enter a comment. Click Next.
- In the Specify the security options window,
specify the security option that will be used for authentication.
- Click Finish. You can now use this
database. Select the Exit menu action to close
the CA.
Configuring a database connection by searching the network
using the Configuration Assistant
You can use the Configuration Assistant (CA) to search
a network for databases.
Before you configure a database connection by searching the
network:
- Ensure that you have a valid DB2 user
ID.
- If you are configuring a connection from a system that has a DB2 Server
or DB2 Connect server product installed,
ensure that you have a user ID with SYSADM or SYSCTRL authority for
the instance.
The search method feature might be unable to detect a remote
system if:
- It is used in a cluster environment.
- The DB2 Administration Server (DAS) is not running
on the remote system.
- The search times out. By default, the search will scan the network
for 1 second; this might not be long enough to detect the remote system.
You can set the DB2DISCOVERYTIME registry variable to specify a longer
period of time.
- The network that the search is running on is configured so that
the search does not reach the remote system required.
The following points apply to cases where you want to explicitly
configure an IPv6 address on a network that supports IPv6:
- The system must be listed under Known Systems.
- Only the Configuration Assistant Advanced View supports explicitly
configure an IPv6 connection.
To configure a database connection by searching the network:
- Log on to the system with a valid DB2 user
ID.
- Start the CA. The CA can be started from the Start menu
on Windows or using the db2ca command
on both Windows and UNIX systems.
- On the CA menu bar, under Selected,
choose Add Database Using Wizard. The Add
Database Wizard opens.
- Select the Search the network radio
button and click Next.
- Double-click the folder beside Known Systems to
list all the systems known to your client or double-click the folder
beside Other Systems to list all the systems
on the network. If no systems are listed, you can click Add
System to specify one. After you add a system, it displays
in the Known Systems list.
- Expand the entries for the system you are interested in
until you see the database you want to add. Select the database. Click Next.
- Type a local database alias name in the Database
alias field and optionally type a comment that describes
this database in the Comment field.
- If you are planning to use ODBC, register this database
as an ODBC data source. ODBC must be installed to perform this operation.
- Click Finish. You can now use the
database you added. Click Close to exit the
CA.
Creating a client profile using the Configuration Assistant
This task involves exporting settings from an existing
client into a client profile using the Configuration Assistant (CA).
This task is part of a larger task of setting up one or more clients using
the settings from an existing client.
To create a client profile using the CA:
- Log on to the system with a valid DB2 user ID.
- Start the CA. The CA can be started from the Start menu on Windows or
using the db2ca command.
- From the Configure menu, select Export
Profile.
- Select one of the following options:
- All
- If you want to create a profile that contains all of the databases cataloged
on your system, and all of the configuration information for this client.
Type a name for your client profile and click Save.
- Database Connections
- If you want to create a profile that contains all of the databases cataloged
on your system without any of the configuration information for this
client. Type a name for your client profile and click Save.
- Customize
- If you want to select a subset of the databases that are cataloged on
your system, or a subset of the configuration information for this client.
In the Customize Export Profile window:
- Type a name for your client profile.
- Select the Database connections checkbox to include
database connections in the client profile.
- From the Available database aliases box, select
the databases to be exported and click > to add
them to the Selected database aliases box. To add all
of the available databases to the Selected database aliases box,
click >>.
- Select the check boxes that correspond to the options that you want to
set up for the target client. Database manager configuration parameters can
be updated and customized for a target machine.
- Click Export to complete this task.
- Check your results displayed in the Results tab.
Once you have completed this task, you can configure other clients
using the client profile you have created.
Configuring database connections using a client profile with the Configuration
Assistant
This task involves configuring a client by using
a client profile that you have created or obtained previously. This
task is part of a larger task of setting up one or more clients using the
settings from an existing client. These steps can be repeated for each client
you want to configure.
- Log on to the system with a valid DB2 user ID.
- Start the CA. The CA can be started from the Start menu on Windows or
using the db2ca command.
- From the Configure menu, select Import
Profile.
- Select one of the following import options. You can choose to import
all or a subset of the information in a client profile.
- All
- Select this option to import everything in a client profile. Open the
client profile you want to import.
- Customize
- Select this option to import a subset of the client profile, such as a
specific database. From the Customize Import Profile window:
- Select the client profile you want to import and click Load.
- Select the databases to be imported from the Available database
aliases box and click > to add them to
the Selected database aliases box. Click >> to
add all of the available databases to the Selected database aliases box.
- Select the check boxes that correspond to the options that you want to
customize.
- Click Import to complete this task.
- Check your results displayed in the Results tab.
Testing a database connection using the Configuration Assistant
After configuration, test your database connection.
To
test a database connection:
- Start the Configuration Assistant.
- Highlight the database in the details view and select Test
Connection from the Selected menu.
The Test Connection window opens.
- Select one or more types of connection that you want to
test (CLI is the default). You can test more
than one type at the same time. Enter a valid user ID and password
for the remote database and click Test Connection.
If the connection is successful, a message confirming the connection
appears on the Results page. If the connection test
failed, you will receive a help message. To change any settings you
might have incorrectly specified, select the database in the details
view and select Change Database from the Selected menu
item.
When setting up a server to work with development environments
(such as IBM Data Studio), you might encounter error message
SQL30081N at the initial DB2 connection. A possible root
cause is that the firewall at the remote database server has prevented
the connection from being established. In this case, verify the firewall
is properly configured to accept connection requests from the client.
LDAP considerations for the Configuration Assistant
In an LDAP-enabled environment, the directory information about DB2 servers
and databases is stored in the LDAP directory. When a new database
is created, the database is automatically registered in the LDAP directory.
During a database connection, the client accesses the LDAP directory
to retrieve the required database and protocol information and uses
this information to connect to the database.
However, you can still use the CA in the LDAP environment to:
- Manually catalog a database in the LDAP directory.
- Register a database cataloged in LDAP as an ODBC data source.
- Configure CLI/ODBC information about the LDAP server.
- Remove a database cataloged in the LDAP directory.
Configuring client-to-server connections using the command
line processor
This task describes how to configure a connection from
an IBM data
server client to
a remote database server using the command line processor (CLP).
Before you configure a client to server connection, ensure:
- Network communications is set up between the machine with the IBM data
server client and
the machine with the DB2 server. One way to verify this
for the TCP/IP protocol is to use the ping command.
- The DB2 server is configured to work on the network.
This is normally done as part of installing and configuring the DB2 server
product.
Separate topics are provided to guide you through each of
the following steps. Some steps have a version for each supported
protocol:
- Identify the communication parameter values for the remote
database server. Worksheets are provided:
- TCP/IP worksheet
- Named Pipes worksheet
- If you are using TCP/IP, you have the option to update the client's hosts file and
services file with communication parameter values for the remote
database server. This step does not apply to Named Pipes.
- Catalog the server node from the client. Instructions are
provided for each communications protocol:
- Catalog the TCP/IP
node from the client.
- Catalog the Named
Pipes node from the client.
- Catalog
the database that you want to connect to on the client.
- Test the client-to-server
connection.
Named pipe connections
Named Pipes worksheet for configuring Named Pipes on the client
Use the following worksheet to help identify the required parameter
values for configuring Named Pipes communications.
Table 20. Named Pipes parameter values worksheet
| Parameter |
Description |
Sample Value |
Your Value |
| Computer name (computer_name) |
The computer name of the server machine.
On
the server machine, to locate the value for this parameter, click on Start and
select Settings, Control Panel. Double-click on the Network folder
and select the Identification tab. Record the computer
name. |
server1 |
|
|
Instance name (instance_name) |
The name of the instance on the server
to which you are connecting. |
db2 |
|
| Node name (node_name) |
A local alias, or nickname, that describes
the node to which you are trying to connect. You can choose any name you want;
however, all node name values within your local node directory must be unique. |
db2node |
|
Cataloging a Named Pipes node from a client using the CLP
Cataloging a Named Pipes node adds an entry to the client's node
directory to describe the remote node. This entry specifies the chosen alias
(node_name), the remote server's workstation
name (computer_name), and the instance (instance_name)
that the client will use to access the remote DB2 server.
To catalog a Named Pipes node on an IBM data
server client, type the following command in the command line
processor (CLP):
db2 => catalog npipe node node_name
db2 => remote computer_name instance instance_name
db2 => terminate
To catalog a remote node called db2node that
is located on a server called server1 in the db2 instance,
use:
db2 => db2 catalog npipe node db2node remote server1 instance db2
db2 => terminate
TCP/IP connections
TCP/IP worksheet for configuring a client to server connection
As you proceed through the configuration steps, use the Your
Value column in the following table to record the required values.
Table 21. TCP/IP parameter values worksheet
| Parameter |
Description |
Sample Value |
Your Value |
|
Version of the IP protocol |
Options are:
- IPv4: addresses look like this 9.21.15.235
- IPv6: addresses look like this: 2001:0db8:4545:2::09ff:fef7:62dc
|
IPv4 |
|
|
Host name
- Hostname (hostname) or
- IP address (ip_address)
|
To resolve the hostname of the remote
system, enter the hostname command at the server.
To
resolve the IP address, enter the ping hostname command. |
myserver
or
9.21.15.235
or
an IPv6 address |
|
|
Service Name
- Connection Service name (svcename) or
- Port number/Protocol (port_number/tcp)
|
Values Required in the services file.
The
Connection Service name is an arbitrary name that represents the connection
port number (port_number) on the client.
The
port number must be the same as the port number that the svcename parameter
maps to in the services file on the server system. (The svcename parameter
is located in the database manager configuration file on the server instance.)
This value must not be in use by any other applications, and must be unique
within the services file.
On Linux or UNIX platforms,
this value generally must be 1024 or higher.
Contact your database
administrator for the values used to configure the server. |
server1
or
3700/tcp |
|
| Node name (node_name) |
A local alias, or nickname, that describes
the node to which you are trying to connect. You can choose any name you want;
however, all node name values within your local node directory must be unique. |
db2node |
|
Updating hosts and services files for TCP/IP connections
This task explains when and how to update the hosts file
and services file on the client with communication
parameter values for the remote database server. This task is optional
for connections using TCP/IP and does not apply to connections using
Named Pipes. This task is part of the larger task of configuring client-to-server
connection using the CLP.
You need to update the hosts file
if you want to establish a connection to the remote database server
using its hostname and your network does not contain a DNS (domain
name server) that can be used to resolve that hostname to an IP address.
This step is not required if you want to refer to the remote database
server using its IP address.
You need to update the services file
if you want to specify a connection service name when establishing
a connection to the remote database server. A connection service is
an arbitrary name that represents the connection port number. This
step is not required if you want to refer to the remote database server's
port number.
Procedure
- To update the hosts file on the client
to resolve the remote server's hostname to its IP address:
- Use a text editor to add an entry to the hosts file
for the server's IP address. For example:
9.26.13.107 myserver # IPv4 address for myserver
2002:91a:519:13:210:83ff:feff:ca71 myserver # IPv6 address for myserver
where:
- 9.26.13.107
- represents the IPv4 ip_address
- 2002:91a:519:13:210:83ff:feff:ca71
- represents the IPv6 ip_address
- myserver
- represents the hostname
- #
- represents a comment describing the entry
Note:
Note that IPv6 entries are not needed
if your host does not belong on an IPv6 network. For hosts in mixed
IPv4 and IPv6 networks, an alternate method is to assign different
host names for IPv4 and IPv6 addresses. For example:
9.26.13.107 myserver # IPv4 address for myserver
9.26.13.107 myserveripv4 # IPv4 address for myserver
2002:91a:519:13:210:83ff:feff:ca71 myserveripv6 # IPv6 address for myserver
If the server is not in the same domain as the IBM data
server client,
you must provide a fully qualified domain name such as myserver.spifnet.ibm.com,
where spifnet.ibm.com represents the domain name.
- To update the services file on the
client to resolve a service name to the remote server's port number:
- Using a text editor, add the Connection Service name
and port number to the services file. For example:
server1 50000/tcp # DB2 connection service port
where:
- server1
- represents the Connection Service name
- 50000
- represents the connection port number (50000 is the default)
- tcp
- represents the communication protocol that you are using
- #
- represents the beginning of a comment that describes the entry
The following table lists the location of the hosts file
and services file referred to in the preceding
procedures.
Table 22. Location of the hosts file and services file
| Operating System |
Directory |
| Windows 2000
XP/Windows Server 2003 |
%SystemRoot%\system32\drivers\etc where %SystemRoot% is
a system defined environment variable |
| Linux or UNIX |
/etc |
Cataloging a TCP/IP node from a client using the CLP
Cataloging a TCP/IP node adds an entry to the Data Server Client node directory that describes the remote node.
This entry specifies the chosen alias (node_name),
the hostname (or ip_address),
and the svcename (or port_number)
that the client uses to access the remote host.
You must have System Administrative (SYSADM) or System Controller
(SYSCTRL) authority, or have the catalog_noauth option set
to ON. You cannot catalog a node using root authority.
To catalog a TCP/IP node:
- Log on to the system as a user with System Administrative (SYSADM)
or System Controller (SYSCTRL) authority.
- If you are using a Linux or UNIX client, set up the instance environment.
Run the start-up script:
- For bash, Bourne or Korn shell
-
. INSTHOME/sqllib/db2profile
- For C shell
-
source INSTHOME/sqllib/db2cshrc
where INSTHOME represents the home
directory of the instance.
- Start the DB2 command line processor. On Windows,
issue the db2cmd command from a command prompt. On Linux or UNIX,
issue the db2 command from a command prompt.
- Catalog the node by entering the following commands in the command
line processor:
db2 => catalog tcpip node node_name remote hostname|ip_address
server service_name|port_number [remote_instance instance_name]
[system system_name] [ostype os_type]
db2 => terminate
where:
- node_name represents a local nickname you can set for
the computer that has the database you want to catalog.
- remote_instance represents the name of the server instance
on which the database resides.
- system_name represents the DB2 system name that is used to identify
the server.
- ostype_name represents the operating system type of the
server.
Note:
- The terminate command is needed to refresh the directory
cache.
- Although remote_instance, system, and ostype are
optional, they are required for users who want to use the DB2 tools.
- The service_name used on the client does not
have to be the same as the one on the server. However, the port numbers that
they map to must match
- While not shown here, the catalog tcpip node command
provides the option to explicitly specify the version of IP, namely IPv4 or
IPv6.
To catalog a node that you want to call db2node on
a remote server myserver.ibm.com that is using port
number 50000, you would enter the following from
a db2 prompt:
db2 => catalog tcpip node db2node remote myserver server 50000
DB20000I The CATALOG TCPIP NODE command completed successfully.
DB21056W Directory changes may not be effective until the directory cache is
refreshed.
db2 => terminate
DB20000I The TERMINATE command completed successfully.
Cataloging a database from a client using the CLP
This task describes how to catalog a database from a client using
the command line processor (CLP).
Before a client application can access a remote database, the database
must be cataloged on the client. When you create a database, the database
is automatically cataloged on the server with a database alias that is the
same as the database name, unless a different database alias was specified.
The information in the database directory, along with the information
in the node directory (unless you are cataloging a local database where a
node is not needed), is used on the IBM data
server client to establish a connection to the remote database.
- You require a valid DB2 user ID. DB2 does not support using root authority
to catalog a database.
- You must have System Administrative (SYSADM) or System Controller (SYSCTRL)
authority, or have the catalog_noauth option set to ON
- You need the following information when cataloging a remote database:
- Database name
- Database alias
- Node name
- Authentication type (optional)
- Comment (optional)
Refer to the parameter values worksheet for cataloging a database for
more information about these parameters and to record the values that you
use.
- The following parameter values are applicable when cataloging a local database:
- Database name
- Drive
- Database alias
- Authentication type (optional)
- Comment (optional)
Local databases can be uncataloged and recataloged at any time.
To catalog a database on the client:
- Log on to the system with a valid DB2 user ID.
- Optional. Update the Your Value column in the Parameter
values worksheet for cataloging a database.
- If you are using the DB2 database on a Linux or UNIX platform,
set up the instance environment. Run the start-up script:
- For bash, Bourne or Korn shell
-
. INSTHOME/sqllib/db2profile
- For C shell
-
source INSTHOME/sqllib/db2cshrc
where: INSTHOME represents the home
directory of the instance.
- Start the DB2 command line processor. On Windows,
issue the db2cmd command from a command prompt. On Linux or UNIX,
issue the db2 command from a command prompt.
- Catalog the database by entering the following commands in the
command line processor:
db2 => catalog database database_name as database_alias at
node node_name [ authentication auth_value ]
where:
- database_name represents the name of the database you
want to catalog.
- database_alias represents a local nickname for the database
you want to catalog.
- node_name represents a nickname you can set for the computer
that has the database you want to catalog.
- auth_value specifies the type of authentication that
will take place when connecting to the database. This parameter defaults to
the authentication type specified on the server. Specifying an authentication
type can result in a performance benefit. Examples of valid values include:
SERVER, CLIENT, SERVER_ENCRYPT, and KERBEROS.
To catalog a remote database called sample so
that it has the local database alias mysample, on
the node db2node using authentication server,
enter the following commands:
db2 => catalog database sample as mysample at node db2node
authentication server
db2 => terminate
Parameter values worksheet for cataloging a database
Use the following worksheet to record the parameter values required
to catalog a database.
Table 23. Catalog database parameter values worksheet
| Parameter |
Description |
Sample Value |
Your Value |
| Database name (database_name) |
When a database is created, the database
alias is set to the database name unless otherwise specified. For example,
when the sample database is created on the server, a database
alias of sample is also created. The database name represents
the remote database alias (on the server). |
sample |
|
| Database alias (database_alias) |
An arbitrary local nickname that represents
the remote database. If you do not provide one, the default is the same as
the database name (database_name). Use this name
when you connect to the database from a client. |
mysample |
|
| Authentication (auth_value) |
The type of authentication required in your environment. |
Server |
|
| 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. |
db2node |
|
Testing the client-to-server connection using the CLP
After cataloging the node and the database, connect to the
database to test the connection. Before testing the connection:
- The database node and database must be cataloged.
- The values for userid and password must
be valid for the system on which they are authenticated. The authentication
parameter on the client is be set to match the value on the server
or it can be left unspecified. If an authentication parameter is not
specified, the client will default to SERVER_ENCRYPT. If the server
does not accept SERVER_ENCRYPT, then the client retries using the
value returned from the server. If the client specifies an authentication
parameter value that doesn't match what is configured on the server,
you will receive an error.
- The database manager must be started with the correct protocol
defined in the DB2COMM registry variable. If it is not started, then
you can start the database manager by entering the db2start command
on the database server.
To test the client to server connection:
- If you are using a Linux or UNIX platform,
set up the instance environment. Run the start-up script:
- For bash, Bourne or Korn shell
-
. INSTHOME/sqllib/db2profile
- For C shell
-
source INSTHOME/sqllib/db2cshrc
where: INSTHOME represents
the home directory of the instance.
- Start the DB2 command line processor. On Windows, issue the db2cmd command
from a command prompt. On Linux or UNIX,
issue the db2 command from a command prompt.
- Type the following command on the client to connect to
the remote database:
db2 => connect to database_alias user userid
For
example, enter the following command:
connect to mysample user jtris
You
will be prompted to enter your password.
If the connection is successful, you receive a message showing
the name of the database to which you have connected. A message similar
to the following is given:
Database Connection Information
Database server = DB2 9.1.0
SQL authorization ID = JTRIS
Local database alias = mysample
You can now work with
the database. For example, to retrieve a list of all the table names
listed in the system catalog table, enter the following SQL statement:
select tabname from syscat.tables
When you are finished using the database connection, enter
the connect reset command to end the database connection.
[ Top of Page | Previous Page | Next Page | Contents ]
DB2 Version 9.7 for Linux, UNIX, and Windows