step 1.
Configure network communications.
 | 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:
- If you catalog an APPC node, the access method is DRDA.
To catalog an APPC node, issue the following command:
CATALOG APPC NODE DB2NODE REMOTE DB2CPIC SECURITY PROGRAM
where:
- DB2NODE is a name that you assign to the node that you are cataloging.
- DB2CPIC is the symbolic destination name of the remote partner node.
- PROGRAM specifies that both a user name and a password are to be included in the allocation request sent to the partner LU.
- If you catalog a TCP/IP node, the access method is DB2RA unless the DB2
family data source is not capable of supporting DB2RA. DB2 for MVS, for
example, does not support DB2RA. In these cases, DRDA is used as the
access method.
To catalog a TCP/IP node, issue the following command:
CATALOG TCPIP NODE DB2NODE REMOTE SYSTEM42 SERVER DB2TCP42
where:
- DB2NODE is a name that you assign to the node that you are cataloging.
- SYSTEM42 is the host name of the system where the data source resides.
- DB2TCP42 is the primary port name that is defined by the data source for use by data source clients.
See 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. See the Administration Guide, Design and Implementation 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. See the Administration Guide, Design and Implementation 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:
- DB2SERVER is a name that you assign to the DB2 data source. This name must be unique.
- DB2/OS390 is the type of DB2 data source to which you are configuring access.
- 6.1 is the version of DB2 for OS/390 that you are accessing.
- DRDA is the wrapper name that you defined in the CREATE WRAPPER statement.
- db2node is the name of the node where DB2SERVER resides. Obtain the node value by issuing the db2 list node directory command at the DB2 data source. This value is case sensitive.
- quarter4 is the name of a database at
DB2SERVER. This value is case sensitive.
Although the node and database values are specified as options, they are required for DB2 data sources. See the SQL Reference, Volume 2 for a comprehensive list of options.
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 TO 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.
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:
- DB2SALES is a unique nickname for the DB2 table or view.
- DB2SERVER.SALESDATA.MIDWEST is a three-part
identifier that follows this format:
data_source_name.remote_schema_name.remote_table_name
See the SQL Reference, Volume 2 for more information about the CREATE NICKNAME statement.
See the Administration Guide, Design and Implementation for more information about nicknames in general.
step 8.
Repeat the previous step for all database objects that you want to create nicknames for.