Understanding DB2: Learning Visually with Examples (2nd Edition)
6.3. Supported Connectivity Scenarios
In this section, we discuss the following four connectivity scenarios in detail.
A DB2 host server can be DB2 for z/OS, OS/390, or iSeries. You can configure a database connection by either:
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. Figure 6.10. The process of connecting locally from a DB2 client to a DB2 Server
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:
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. Figure 6.11. The process of connecting remotely from a DB2 client to a DB2 server
In this configuration, the machine Libra is considered a client to database server Aries. The client must have one of the following installed:
The server must have one of the following installed:
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.
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.
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.
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.
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. Figure 6.12. Sample client's system database directory and node directory for remote connection to a DB2 database
6.3.2.2.2 NetBIOS Connection
If you are using NetBIOS, use the information in Table 6.4 to catalog a NetBIOS node.
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.
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. Figure 6.13. The process of connecting remotely from a DB2 client to a DB2 host server
The client must have one of the following installed:
The communication protocols supported are
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.
Table 6.7 demonstrates how to use these commands based on the example shown in Figure 6.15.
Figure 6.15. The process of connecting from a DB2 client to a DB2 server via a DB2 Connect gateway
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. Figure 6.14. Sample client's system database directory, node directory, and DCS directory for remote connection to a DB2 host database
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:
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.
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.
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. NOTE The 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. NOTE You must have BINDADD authority to create a new package in a database or BIND privilege if the package already exists. |