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 ]