Step 1.
| Configure network communications.
![Figure 00002671 not displayed.](00002671.gif)
| Configuring your federated server to access DB2 family data sources is
similar to configuring a client to communicate with a DB2 server.
Configuration instructions are provided in:
|
|
Step 2.
| Catalog an entry in the federated server's node directory that points
to the location of the DB2 data source. The federated server determines
the access method to use based upon the type of node being cataloged and the
type of DB2 family database being accessed.
Refer to the Command Reference for more information about these commands.
|
Step 3.
| Use the CREATE WRAPPER statement to define the wrapper module that will be
used to access DB2 data sources. Wrappers are the mechanism that
federated servers use to communicate with and retrieve data from data
sources. The following example shows a CREATE WRAPPER statement:
CREATE WRAPPER DRDA
where DRDA is the default name of the wrapper module used to
access DB2 family data sources.
You can substitute the default name with a name that you choose;
however, if you do so, you also must include the LIBRARY parameter and the
name of the wrapper library for your federated server platform. Refer
to the SQL Reference for more information about wrapper libraries.
|
Step 4.
| Optional: Set the DB2_DJ_COMM environment variable to include the
wrapper library that corresponds to the wrapper module that you created in the
previous step; for example:
db2set DB2_DJ_COMM = libdrda.a
The DB2_DJ_COMM environment variable controls whether a wrapper module is
loaded when the federated server initializes, which can result in improved
performance when the DB2 family data source is first accessed. Refer to
the SQL Reference for more information about wrapper library names.
|
Step 5.
| Use the CREATE SERVER statement to define each DB2 server to which
communications are configured; for example:
CREATE SERVER DB2SERVER TYPE DB2/OS390 VERSION 6.1 WRAPPER DRDA
OPTIONS (NODE 'db2node', DBNAME 'quarter4')
where:
|
Step 6.
| If a user ID or password at the federated server is different from a user
ID or password at a DB2 family data source, use the CREATE USER MAPPING
statement to map the local user ID to the user ID and password defined at the
DB2 family data source; for example:
CREATE USER MAPPING FOR DB2USER SERVER DB2SERVER
OPTIONS ( REMOTE_AUTHID 'db2admin', REMOTE_PASSWORD 'dayl1te')
where:
- DB2USER is the local user ID that you are mapping to a user ID
defined at a DB2 family data source.
- DB2SERVER is the name of the DB2 family data source that you
defined in the CREATE SERVER statement.
- db2admin is the user ID at the DB2 family data source to which
you are mapping DB2USER. This value is case
sensitive.
- dayl1te is the password associated with
db2admin. This value is case sensitive.
|
Step 7.
| Use the CREATE NICKNAME statement to assign a nickname to a view or table
located at your DB2 family data source. You will use this nickname when
you query the DB2 family data source. The following example shows a
CREATE NICKNAME statement:
CREATE NICKNAME DB2SALES FOR DB2SERVER.SALESDATA.MIDWEST
where:
Refer to the SQL Reference for more information about the CREATE NICKNAME statement.
Refer to the Administration Guide for more information about nicknames in general.
|
Step 8.
| Repeat the previous step for all database objects that you want to create
nicknames for.
|