Release Notes


6.6 Accessing Sybase Data Sources

Before you add Sybase data sources to a federated server, you need to install and configure the Sybase Open Client software on the DB2 federated server. See the installation procedures in the documentation that comes with Sybase database software for specific details on how to install the Open Client software. As part of the installation, make sure that you include the Sybase catalog stored procedures are installed on the Sybase server and the Sybase Open Client libraries are installed on the DB2 federated server.

After configuring the connection from the client software to the Sybase server, test the connection using one of the Sybase tools. Use the isql tool for UNIX and the SQL Advantage tool for Windows.

To set up your federated server to access data stored on Sybase data sources, you need to:

  1. Install DB2 Relational Connect Version 7.2. See 6.3.4, Installing DB2 Relational Connect.
  2. Add Sybase data sources to your federated server.
  3. Specify the Sybase code pages.

This chapter discusses steps 2 and 3.

The instructions in this chapter apply to Windows NT, AIX, and the Solaris Operating Environment. The platform-specific differences are noted where they occur.

6.6.1 Adding Sybase Data Sources to a Federated Server

To add a Sybase data source to a federated server, you need to:

  1. Set the environment variables and update the profile registry (AIX and Solaris only).
  2. Link DB2 to Sybase client software (AIX and Solaris only).
  3. Recycle the DB2 instance (AIX and Solaris only).
  4. Create and set up an interfaces file.
  5. Create the wrapper.
  6. Optional: Set the DB2_DJ_COMM environment variable.
  7. Create the server.
  8. Optional: Set the CONNECTSTRING server option.
  9. Create a user mapping.
  10. Create nicknames for tables and views.

These steps are explained in detail in this section.

6.6.1.1 Step 1: Set the environment variables and update the profile registry (AIX and Solaris only)

Set data source environment variables by modifying the db2dj.ini file and issuing the db2set command. The db2dj.ini file contains configuration information about the Sybase client software installed on your federated server. The db2set command updates the DB2 profile registry with your settings.

In a partitioned database system, you can use a single db2dj.ini file for all nodes in a particular instance, or you can use a unique db2dj.ini file for one or more nodes in a particular instance. A nonpartitioned database system can have only one db2dj.ini file per instance.

To set the environment variables:

  1. Edit the db2dj.ini file located in sqllib/cfg, and set the following environment variable:
     SYBASE="<sybase home directory>"
     
    

    where <sybase home directory> is the directory where the Sybase client is installed.

  2. Issue the db2set command to update the DB2 profile registry with your changes. The syntax of this command, db2set, is dependent upon your database system structure. This step is only necessary if you are using the db2dj.ini file in any of the following database system structures:

    If you are using the db2dj.ini file in a nonpartitioned database system, or if you want the db2dj.ini file to apply to the current node only, issue:

    db2set DB2_DJ_INI=$HOME/sqllib/cfg/db2dj.ini
    

    If you are using the db2dj.ini file in a partitioned database system, and you want the values in the db2dj.ini file to apply to all nodes within this instance, issue:

    db2set -g DB2_DJ_INI=$HOME/sqllib/cfg/db2dj.ini
    

    If you are using the db2dj.ini file in a partitioned database system, and you want the values in the db2dj.ini file to apply to a specific node, issue:

    db2set -i INSTANCEX  3 DB2_DJ_INI=$HOME/sqllib/cfg/node3.ini 
    

    where:

    INSTANCEX
    Is the name of the instance.

    3
    Is the node number as listed in the db2nodes.cfg file.

    node3.ini
    Is the modified and renamed version of the db2dj.ini file.

6.6.1.2 Step 2: Link DB2 to Sybase client software (AIX and Solaris Operating Environment only)

To enable access to Sybase data sources, the DB2 federated server must be link-edited to the client libraries. The link-edit process creates a wrapper for each data source with which the federated server will communicate. When you run the djxlink script you create the wrapper library. To issue the djxlink script type:

djxlink

6.6.1.3 Step 3: Recycle the DB2 instance (AIX and Solaris Operating Environment only)

To ensure that the environment variables are set in the program, recycle the DB2 instance. When you recycle the instance, you refresh the DB2 instance to accept the changes that you made.

Issue the following commands to recycle the DB2 instance:

On DB2 for Windows NT servers:
NET STOP instance_name
NET START instance_name

On DB2 for AIX and Solaris servers:
db2stop
db2start

6.6.1.4 Step 4: Create and set up an interfaces file

To create and set up an interfaces file, you must create the file and make the file accessible.

  1. Use the Sybase-supplied utility to create an interfaces file that includes the data for all the Sybase Open Servers that you want to access. See the installation documentation from Sybase for more information about using this utility.

    Windows NT typically names this file sql.ini. Rename the file you just created from sql.ini to interfaces to name the file universally across all platforms. If you choose not to rename sql.ini to interfaces you must use the IFILE parameter or the CONNECTSTRING option that is explained in step 8.

    On AIX and Solaris systems this file is named <instance home>/sqllib/interfaces.

  2. Make the interfaces file accessible to DB2.

    On DB2 for Windows NT servers:
    Put the file in the DB2 instance's %DB2PATH% directory.

    On DB2 for AIX and Solaris servers:
    Put the file in the DB2 instance's $HOME/sqllib directory. Use the ln command to link to the file from the DB2 instance's $HOME/sqllib directory. For example:
    ln -s -f /home/sybase/interfaces  /home/db2djinst1/sqllib
    

6.6.1.5 Step 5: Create the wrapper

Use the CREATE WRAPPER statement to specify the wrapper that will be used to access Sybase data sources. Wrappers are mechanisms that federated servers use to communicate with and retrieve data from data sources. DB2 includes two wrappers for Sybase, CTLIB and DBLIB. The following example shows a CREATE WRAPPER statement:

CREATE WRAPPER CTLIB 

where CTLIB is the default wrapper name used with Sybase Open Client software. The CTLIB wrapper can be used on Windows NT, AIX, and Solaris servers.

You can substitute the default wrapper name with a name that you choose. However, if you do so, you must also include the LIBRARY parameter and the name of the wrapper library for your federated server in the CREATE WRAPPER statement. See the CREATE WRAPPER statement in the DB2 SQL Reference for more information about wrapper library names.

6.6.1.6 Step 6: Optional: Set the DB2_DJ_COMM environment variable

To improve performance when the Sybase data source is accessed, set the DB2_DJ_COMM environment variable. This variable determines whether a wrapper is loaded when the federated server initializes. Set the DB2_DJ_COMM environment variable to include the wrapper library that corresponds to the wrapper that you specified in the previous step; for example:

On DB2 for AIX servers:
db2set DB2_DJ_COMM='libctlib.a' 

On DB2 for Solaris servers:
db2set DB2_DJ_COMM='libctlib.so' 

Ensure that there are no spaces on either side of the equal sign (=).

Refer to the DB2 SQL Reference for more information about wrapper library names. Refer to the Administration Guide for information about the DB2_DJ_COMM environment variable.

6.6.1.7 Step 7: Create the server

Use the CREATE SERVER statement to define each Sybase server whose data sources you want to access; for example:

CREATE SERVER SYBSERVER TYPE SYBASE VERSION 12.0 WRAPPER CTLIB
OPTIONS (NODE 'sybnode', DBNAME'sybdb')

where:

SYBSERVER
Is a name that you assign to the Sybase server. This name must be unique.

SYBASE
Is the type of data source to which you are configuring access. Sybase is the only data source that is supported.

12.0
Is the version of Sybase that you are accessing. The supported versions are 10.0, 11.0, 11.1, 11.5, 11.9, and 12.0.

CTLIB
Is the wrapper name that you specified in the CREATE WRAPPER statement.

'sybnode'
Is the name of the node where SYBSERVER resides. Obtain the node value from the interfaces file. This value is case-sensitive.

Although the name of the node is specified as an option, it is required for Sybase data sources. See the DB2 SQL Reference for information on additional options.

'sybdb'
Is the name of the Sybase database that you want to access. Obtain this name from the Sybase server.

You can use the IGNORE_UDT server option with CTLIB and DBLIB protocols to specify whether the federated server should determine the built-in type that underlies a UDT without strong typing. This server option applies only to data sources accessed through the CTLIB and DBLIB protocols. Valid values are:

'Y'
Ignore the fact that UDTs are user-defined and determine what built-in types under lie them.

'N'
Do not ignore user-defined specifications of UDTs. This is the default setting.

When DB2 creates nicknames, it looks for and catalogs information about the objects (tables, views, stored procedures) that the nicknames point to. As it looks for the information, it might find that some objects have data types that it doesn't recognize (that is, data types that don't map to counterparts at the federated database). Such unrecognizable types can include:

When the federated server finds data types that it does not recognize, it returns the error message, SQL3324N. However, it can make an exception to this practice. For data sources accessible through the CTLIB or DBLIB protocols, you can set the IGNORE_UDT server option so that when the federated database encounters an unrecognizable UDT without strong typing, the federated database determines what the UDT's underlying built-in type is. Then, if the federated database recognizes this built-in type, the federated database returns information about the built-in type to the catalog. To have the federated database determine the underlying built-in types of UDTs that do not have strong typing, set IGNORE_UDT to 'Y'.

6.6.1.8 Step 8: Optional: Set the CONNECTSTRING server option

Specify the timeout thresholds, the path and name of the interfaces file, and the packet size of the interfaces file. Sybase Open Client uses timeout thresholds to interrupt queries and responses that run for too long a period of time. You can set these thresholds in DB2 by using the CONNECTSTRING option of the CREATE SERVER OPTION DDL statement. Use the CONNECTSTRING option to specify:

   .-;-------------------------------.
   V                                 |
>>---+-----------------------------+-+-------------------------><
     +-TIMEOUT-- = --seconds-------+
     +-LOGIN_TIMEOUT-- = --seconds-+
     +-IFILE-- = --"string"--------+
     +-PACKET_SIZE-- = --bytes-----+
     '-;---------------------------'
 
 
TIMEOUT
Specifies the number of seconds for DB2 Universal Database to wait for a response from Sybase Open Client for any SQL statement. The value of seconds is a positive whole number in DB2 Universal Database's integer range. The timeout value that you specify depends on which wrapper you are using. Windows NT, AIX, and Solaris servers are all able to utilize the DBLIB wrapper. The default value for the DBLIB wrapper is 0. On Windows NT, AIX, and Solaris servers the default value for DBLIB causes DB2 Universal Database to wait indefinitely for a response.
LOGIN_TIMEOUT
Specifies the number of seconds for DB2 Universal Database to wait for a response from Sybase Open Client to the login request. The default values are the same as for TIMEOUT.
IFILE
Specifies the path and name of the Sybase Open Client interfaces file. The path that is identified in string must be enclosed in double quotation marks ("). On Windows NT servers, the default is %DB2PATH%. On AIX and Solaris servers, the default value is sqllib/interfaces in the home directory of your DB2 Universal Database instance.
PACKET_SIZE
Specifies the packet size of the interfaces file in bytes. If the data source does not support the specified packet size, the connection will fail. Increasing the packet size when each record is very large (for example, when inserting rows into large tables) significantly increases performance. The byte size is a numeric value. See the Sybase reference manuals for more information.

Examples:

On Windows NT servers, to set the timeout value to 60 seconds and the interfaces file to C:\etc\interfaces, use:

CREATE SERVER OPTION connectstring FOR SERVER sybase1
SETTING 'TIMEOUT=60;LOGIN_TIMEOUT=5;IFILE="C:\etc\interfaces"'
 

On AIX and Solaris servers, set the timeout value to 60 seconds and the interfaces file to/etc/interfaces, use:

CREATE SERVER OPTION connectstring FOR SERVER sybase1
SETTING 'TIMEOUT=60;PACKET_SIZE=4096;IFILE="/etc/interfaces"'
 

6.6.1.9 Step 9: Create a user mapping

If a user ID or password on the federated server is different from a user ID or password on a Sybase data source, use the CREATE USER MAPPING statement to map the local user ID to the user ID and password defined at the Sybase data source; for example:

CREATE USER MAPPING FOR DB2USER SERVER SYBSERVER
OPTIONS ( REMOTE_AUTHID 'sybuser', REMOTE_PASSWORD 'day2night')

where:

DB2USER
Is the local user ID that you are mapping to a user ID defined at an Sybase data source.

SYBSERVER
Is the name of the Sybase data source that you defined in the CREATE SERVER statement.

'sybuser'
Is the user ID at the Sybase data source to which you are mapping DB2USER. This value is case sensitive.

'day2night'
Is the password associated with 'sybuser'. This value is case sensitive.

See the DB2 SQL Reference for more information on additional options.

6.6.1.10 Step 10: Create nicknames for tables and views

Assign a nickname for each view or table located at your Sybase data source. You will use these nicknames when you query the Sybase data source. Sybase nicknames are case sensitive. Enclose both the schema and table names in double quotation marks ("). The following example shows a CREATE NICKNAME statement:

CREATE NICKNAME SYBSALES FOR SYBSERVER."salesdata"."europe"

where:

SYBSALES
Is a unique nickname for the Sybase table or view.

SYBSERVER."salesdata"."europe"
Is a three-part identifier that follows this format:

data_source_name."remote_schema_name"."remote_table_name"

Repeat this step for each table or view to which you want create nicknames. When you create the nickname, DB2 will use the connection to query the data source catalog. This query tests your connection to the data source. If the connection does not work, you receive an error message.

See the DB2 SQL Reference for more information about the CREATE NICKNAME statement. For more information about nicknames in general and to verify data type mappings, see the DB2 Administration Guide.

6.6.2 Specifying Sybase code pages

This step is necessary only when the DB2 federated server and the Sybase server are running different code pages. Data sources that are using the same code set as DB2 require no translation. The following table provides equivalent Sybase options for common National Language Support (NLS) code pages. Either your Sybase data sources must be configured to correspond to these equivalents, or the client code must be able to detect the mismatch and flag it as an error or map the data by using its own semantics. If no conversion table can be found from the source code page to the target code page, DB2 issues an error message. Refer to your Sybase documentation for more information.

Table 2. Sybase Code Page Options

Code page Equivalent Sybase option
850 cp850
897 sjis
819 iso_1
912 iso_2
1089 iso_6
813 iso_7
916 iso_8
920 iso_9


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]