Learning Visually with Examples [Electronic resources] نسخه متنی

6.3. Supported Connectivity Scenarios

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.

6.3.1. Scenario 1: Local Connection from a DB2 Client to a DB2 Server

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.

NOTE

If 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.

6.3.2. Scenario 2: Remote Connection from a DB2 Client to a DB2 Server

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 Workgroup 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

To configure the connection shown in Figure 6.11, you need to:

The following sections describe these steps.

6.3.2.1 Enabling the Database Server to Accept Client Connections

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.

6.3.2.1.1 TCP/IP connection

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.

service_name   port_number/tcp 

update dbm cfg using svcename  
port_number 
/ 
service_name 

db2set DB2COMM=TCPIP 

NOTE

If 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.

6.3.2.1.2 NetBIOS or Named Pipes Connection

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.

update dbm cfg using nname  
value 

update dbm cfg using nname server1 

db2set DB2COMM=NETBIOS 

db2set DB2COMM=NPIPE 

6.3.2.2 Cataloging the Node Directory and Database Directory on the Client

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.

6.3.2.2.1 TCP/IP Connection

Use the information in Table 6.2 for completing the procedure in this section.

catalog tcpip node    
nodename 
remote  
hostname_or_IP_address_of_server 
server  
port_number_of_server 

catalog db database_name [as database_alias] at node nodename 

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.

db2 catalog tcpip node mynode1 
remote aries.myacme.com 
server 50000 

db2 catalog db rmtdb 
as myrmtdb 
at node mynode1 

db2 terminate 

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.

6.3.2.2.2 NetBIOS Connection

If you are using NetBIOS, use the information in Table 6.4 to catalog a NetBIOS node.

catalog netbios node     
nodename 
remote   
nname_of_server 
adapter  
adapter_number 

6.3.2.2.3 Named Pipes Connection

If you are using Named Pipes as the communication protocol, use the worksheet in Table 6.5 to catalog an NPIPE node.

catalog npipe node      
nodename 
remote    
computer_name_of_server 
instance  
instance_name 

6.3.3. Scenario 3: Remote Connection from a DB2 Client to a DB2 Host Server

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.

6.3.3.1 Enabling the Database Server to Accept Client Connections

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.

6.3.3.2 Cataloging the Node Directory, Database Directory, and DCS Directory on the Client

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.

6.3.3.2.1 TCP/IP Connection

Use the information in Table 6.6 for completing the procedure in this section.

catalog tcpip node    
nodename 
remote  
hostname_or_IP_address_of_server 
server  
port_number_of_server 

catalog db  
database_name [as database_alias] at node nodename 

catalog dcs db  
database_name as target_database_name 

terminate 

Table 6.7 demonstrates how to use these commands based on the example shown in Figure 6.15.

db2 catalog tcpip node mynode2 
remote mpower.youracme.com 
server 44 

db2 catalog db  
myhostdb 
at node  
mynode2 

db2 catalog dcs db myhostdb 
as hostprod 

db2 terminate 

db2 connect to myhostdb user  
userid  
using  
password 

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.

6.3.3.2.2 APPC Connection

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.

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.

6.3.4. Scenario 4: Remote Connection from a DB2 Client to a DB2 Host Server via a DB2 Connect Gateway

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.

6.3.5. Binding Utilities

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_directory \bnd 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.