In this section, we discuss the following four connectivity scenarios in detail.
Scenario 1: Local connection from a DB2 client to a DB2 server
Scenario 2: Remote connection from a DB2 client to a DB2 server
Scenario 3: Remote connection from a DB2 client to a DB2 host server
Scenario 4: Remote connection from a DB2 client to a DB2 host server through a DB2 Connect gateway
A DB2 host server can be DB2 for z/OS, OS/390, or iSeries.
You can configure a database connection by either:
Cataloging the DB2 directories using DB2 commands manually
Using the Configuration Assistant (CA) GUI tool
The Configuration Assistant is explained in section 6.4, Configuring Database Connections Using the Configuration Assistant.
It is useful to understand how to manually populate the DB2 directories using DB2 commands, so these scenarios focus on using the commands. Once you know how to do this, it will be a breeze to perform the configuration with the Configuration Assistant.
Figure 6.10 illustrates a local connection.
Even though Figure 6.10 shows two machines, Machine 1 and Machine 2, Machine 1 is used to connect to Machine 2 using operating system commands or utilities like the Windows Terminal Service or Remote Desktop Connection (on Windows) or telnet (on Linux/UNIX). Once you establish this connection, any command you issue from the keyboard at Machine 1 is equivalent to issuing the command locally at Machine 2. Under this setup, when the connect to database statement is issued from the keyboard at either Machine 1 or Machine 2, the connection is considered local.
In this configuration, the server must have one of the following installed:
DB2 Personal Edition
DB2 Workgroup Edition
DB2 Express Edition
DB2 Enterprise Server Edition
The database must exist in the server's system database directory with an entry type of Indirect.
When you create a database with the create database command, an entry is automatically created in the system database directory and the local database directory. You normally do not need to issue catalog commands for a local database. However, it is possible for a local database to get lost in the system database directory. For example, this can happen if someone issues the uncatalog database command to remove the database from the system database directory, or when the system database directory is reset when reinstalling DB2. In all cases, as long as the database was not dropped (either by the drop database command or using the Control Center), the database still physically exists on the system, and the entry in the system database directory is simply missing. To get the database back into the system database directory, use this command:
catalog db database_name [as database_alias] [on drive/path]
where:
drive (Windows)/path (UNIX) is the location where the database files are physically stored.
Once the database is cataloged, you can use it just like before.
NOTEIf you drop an instance, the databases that belong to this instance are not dropped, because the databases reside on different directories from that of the instance. To recover these databases, all you need to do is to create a new instance with the same name as the one dropped and catalog the databases back using the catalog db command. |
In most cases you do not have the authority to log on to the database server to perform a local database connection. Database servers are set up so that connections are performed through DB2 clients. In this scenario, DB2 client code is installed on a different machine from the database server machine. The connect statement is issued from the DB2 client machine. Figure 6.11 shows a connection from the machine Libra to a remote DB2 server that resides on Aries.
In this configuration, the machine Libra is considered a client to database server Aries. The client must have one of the following installed:
DB2 Client (Runtime, Administration, or Application Development Client)
DB2 Personal Edition
DB2 Express Edition
DB2 Enterprise Server Edition
The server must have one of the following installed:
DB2 Workgroup Edition
DB2 Express Edition
DB2 Enterprise Server Edition
The supported communication protocols are
• TCP/IP | |
• NetBIOS | (only if both the client and server are Windows) |
• Named Pipes | (only if both the client and server are Windows) |
To configure the connection shown in Figure 6.11, you need to:
1. | Enable the database server to accept client connections. |
2. | Catalog the node directory and the system database directory on the client. |
The following sections describe these steps.
Clients connect to the database server across the network using TCP/IP, NetBIOS (Windows only), or Named Pipes (Windows only). The server must have a process that is constantly up and running to receive these connect requests. We call this process a listener because it “listens” to any request that comes in from the network and tells the database manager to serve it.
You need to perform the following steps on the database server to set up the listener if you are using the TCP/IP communication protocol.
1. | Update the services file to reserve a TCP/IP port for the DB2 instance. On Linux/UNIX, the services file is located in /etc/services. On Windows, the services file is located in C:WindowsSystem32driversetcservices. The entry in the services file must look like this: service_name port_number/tcp
where: service_name is an arbitrary name to associate with the port number. port_number is the TCP/IP port number you are going to reserve for this DB2 instance. The port number must not already exist in the services file, and it must have a value of 1024 or higher. |
2. | Update the SVCENAME parameter in the Database Manager Configuration file. Log on as the local administrator (Windows) or the instance owner (Linux/UNIX) and issue the following command from the Command Line Processor: update dbm cfg using svcename port_number/service_name You need to specify either the port number or the service name you defined in step 1. |
3. | Enable TCP/IP support for the instance. Issue the following command: db2set DB2COMM=TCPIP
|
4. | Restart the instance to make the changes you made in the previous steps effective. Issue db2stop and db2start. |
NOTEIf you are working with the default instance created and configured by the DB2 Setup Wizard, the services file, SVCENAME, and the DB2COMM parameters are already correctly configured. |
NetBIOS and Named Pipes are supported when the client and the server are on Windows platforms only. When NetBIOS or Named Pipes are used, you need to execute the following steps to set up the server.
After enabling the server to accept client connections, you need to tell the client how to connect to the server. You do this by cataloging the node directory and the system database directory at the client.
Use the information in Table 6.2 for completing the procedure in this section.
1. | Catalog a TCP/IP node on the client: catalog tcpip node nodename remote hostname_or_IP_address_of_server server port_number_of_server |
2. | Catalog a database directory on the client: catalog db database_name [as database_alias] at node nodename
|
3. | Issue a terminate command to refresh the cache: terminate
|
Table 6.3 demonstrates how to use these commands based on the example shown in Figure 6.11. The information in this table applies to Linux, UNIX, and Windows.
Information You Need to Obtain from Server Machine 2 (Aries) to Perform the Commands on Client Machine 1 | Command to Run on Client Machine 1 (Libra) |
---|---|
Host name = aries.myacme.com TCP/IP port in services file = 50000 |
db2 catalog tcpip node mynode1 remote aries.myacme.com server 50000 |
Database alias on Machine 2 = RMTDB
Note: The database must exist in the system database directory of Machine 2. If the database alias and the database name are different, then the database alias should be used. |
db2 catalog db rmtdb as myrmtdb at node mynode1 Note: MYRMTDB is an alias to the database RMTDB. It is optional; if specified, the alias is what you should use in the connect command. Otherwise, use the database name. |
No information needed. |
db2 terminate
Note: This command is needed to make the previous catalog commands effective. |
A valid user ID and password that has CONNECT privileges to database RMTDB. This user ID will be used from Machine 1 to connect to RMTDB. |
db2 CONNECT TO myrmtdb USER userid USING password |
After completing the two catalog commands in Table 6.3, the client machine's database directory and node directory will look like Figure 6.12.
If you are using NetBIOS, use the information in Table 6.4 to catalog a NetBIOS node.
1. | Issue the command: catalog netbios node nodename remote nname_of_server adapter adapter_number where: nodename is an arbitrary name and it must be unique in the client's node directory. |
2. |
If you are using Named Pipes as the communication protocol, use the worksheet in Table 6.5 to catalog an NPIPE node.
1. | Issue the command: catalog npipe node nodename remote computer_name_of_server instance instance_name where: nodename is an arbitrary name. It must be unique in the client's node directory. |
2. |
Parameter | Description | Sample Value |
---|---|---|
Computer name | The computer name of the server. On the server machine, click on Start > Settings > Control Panel. Double-click on the Network folder and select the Identification tab. Record the computer name. | db2server1 |
Instance name | The name of the DB2 instance on the server. | DB2 |
Figure 6.13 illustrates the configuration used for this scenario. The machine aries is considered a client to the database server mpower.
The client must have one of the following installed:
DB2 Connect Personal Edition
DB2 Connect Enterprise Edition
DB2 Enterprise Server Edition
The communication protocols supported are
TCPIP
APPC
Setting up a remote connection to a host DB2 database follows the same principle as setting up a connection to a DB2 for Linux, UNIX, and Windows database. You need to configure both the client and the server.
3. | Enable the database server to accept client connections. |
4. | Catalog the node directory, system database directory, and DCS directory on the client. |
For DB2 for z/OS and OS/390, make sure that the distributed data facility (DDF) is running on the mainframe. DDF is the facility in DB2 for z/OS and OS/390 that allows for remote communication support. You can verify this by issuing the -display ddf command from the mainframe. To start DDF, issue the -start ddf command.
For DB2 for iSeries, make sure the distributed data management (DDM) is started. DDM is the facility in DB2 for iSeries that allows for remote communication support. To start DDM from the iSeries server or to verify that DDM is already started issue
STRTTCPSVR SERVER(*DDM)
The TCPIP port 446 is usually the default value. APPC can also be used instead of TCP/IP. Contact your host database administrator for specific connection information.
After you have enabled the server to accept client connections, you need to tell the client how to connect to the server. You do this by cataloging the node directory, system database directory, and DCS directory on the client.
Use the information in Table 6.6 for completing the procedure in this section.
1. | Catalog a TCP/IP node on the client. catalog tcpip node nodename remote hostname_or_IP_address_of_server server port_number_of_server |
2. | Catalog a database directory on the client. catalog db database_name [as database_alias] at node nodename |
3. | Catalog a DCS database directory on the client by issuing the following command from the client's command window: catalog dcs db database_name as target_database_name The database_name field must match the database_name in the catalog db command in step 2. |
4. | Issue the terminate command to refresh the cache. terminate
|
Table 6.7 demonstrates how to use these commands based on the example shown in Figure 6.15.
After completing the three catalog commands in Table 6.7, the client machine's system database directory and node directory will look as shown in Figure 6.14.
If you use APPC instead of TCP/IP, you need to do more work on the client. In addition to cataloging the node, database, and DCS directories, you also need to configure the APPC software installed on the client. Table 6.8 lists the supported APPC software. Please refer to the APPC software manual for instructions on how to configure this software.
Platform | Software Needed to Support APPCConnection |
---|---|
Windows NT/2000 | IBM Communications Server Version 6.1.1 or later
IBM Personal Communications for Windows Version 6.0 with CSD 3 Microsoft SNA Server Version 3 with Service Pack 3 or later |
Windows XP | IBM Personal Communications for Windows Version 6.5 with APAR IC23490 |
Windows Server 2003 | APPC is not supported |
AIX | IBM Communications Server for AIX Version 6.1 or later |
HP-UX | SNAplus2 Link R6.11.00.00 SNAplus2 API R.6.11.00.00 |
Linux | APPC is not supported |
Solaris | SNAP-IX for Solaris V7.02 |
After you have configured the APPC software, make sure the client can reach the host machine. This is similar to the ping test in TCP/IP. Then catalog the node, database, and DCS directories. You catalog the database and DCS directories the same way as TCP/IP (see section 6.3.3.2.1, TCP/IP Connection). However, the node directory is cataloged differently. Use the following command to catalog the node directory on the client:
catalog appc node nodename remote symbolic_destination_name security security_type
where:
nodename is an arbitrary name. It must be unique in the client's node directory.
symbolic_destination_name can be found in the CPI-C Side Information profile. You should have created this during the APPC software configuration.
security_type is SAME, SECURITY, or PROGRAM.
Imagine you have 1,000 clients who need to connect to a host database. If you set up the connections using DB2 Connect Personal Edition, you will need to purchase and install DB2 Connect Personal Edition on each of the 1,000 clients. This would be very costly. Wouldn't it be nice if you could only install DB2 Connect once on one machine, and use it as a gateway to service all connections from clients to the host database? Of course! For that scenario you need to use the DB2 Connect Enterprise Edition. Figure 6.15 illustrates this scenario.
In this configuration, Machine 1 is the client, Machine 2 is referred to as the DB2 Connect gateway, and Machine 3 is the host database server.
The DB2 Connect gateway is the only machine that needs to have DB2 Connect Enterprise Edition installed. Its task is to serve as a middleman between the clients and the host database server, since the clients do not have the ability to connect directly to the server. The gateway machine can serve hundreds of clients.
When configuring this type of connection, you can break the three-tier connection into two parts.
Part one is the gateway-to-host server connection. This is identical to what we discussed in Scenario 3. Follow the same steps as in section 6.3.3, Scenario 3: Remote Connection from a DB2 Client to a DB2 Host Server, to configure the gateway. Make sure you can connect from the gateway to the host database before proceeding to the next step.
Part two is the client-to-gateway connection. From the client's perspective, the gateway machine is the database server. (The client does not know anything about the host server mpower.) Thus, when cofiguring this part of the connection, treat the gateway as the server, and follow the same steps described in section 6.3.2, Scenario 2: Remote Connection from a DB2 Client to a DB2 Server.
After a client establishes a connection to a database server, it should be able to access the data in the database. However, if you issue the import/export commands or try to run a CLI/ODBC application, you will get SQL0805N “Package not found” error. This is because the client has not bound these utilities to the database server.
Utilities are database programs with embedded SQL; their packages must reside on the database server. Packages are version and FixPak level specific; therefore, a package created at the Version 8, FixPak 1 level cannot be used by a client running at Version 8, FixPak 2. If this client needs to use these utilities, it must create packages at its own DB2 level. (Refer to Chapter 7, Working with Database Objects, for a more detailed explanation of packages.)
To create all of these packages at once, run the following commands from a DB2 Administration Client or the Application Development Client's CLP window:
connect to database_alias user userid using password bind @db2ubind.lst blocking all grant public bind @db2cli.lst blocking all grant public
If the database server is a host database, you must run one of the following commands on the DB2 Connect machine.
If the host is DB2 for z/OS or OS/390:
bind @ddcsmvs.lst blocking all grant public
If the host is DB2 for iSeries:
bind @ddcs400.lst blocking all grant public
You need to use the symbol @ when you specify a file that contains a list of bind files (with the .lst file extension), rather than a bind file (with the .bnd file extension) itself. The .lst files are in the install_directorynd directory on Windows and in the instance_home/sqllib/bnd directory on Linux/UNIX. Both contain a list of bind files the bind command will run against. A package is created for each of these bind files.
NOTEThe DB2 Runtime Client does not include the required bind files, so you cannot run the bind command from a Runtime Client. |
You must bind the utilities for each database you want to access. Binding only needs to be done once by a client. Once a package is successfully bound to the database, all DB2 clients of the same DB2 version and FixPak level can use it. If you have different versions and FixPaks of clients, you must bind the utilities for each client version and FixPak level.
NOTEYou must have BINDADD authority to create a new package in a database or BIND privilege if the package already exists. |