Step1:

Locate ".odbc.ini" hidden file in DSENGINE folder

Step2:
change the below code to config the ODBC database and add it in the ".odbc.ini"
file
ADD THE BELOW CODE IN HEADER
[ODBC Data Sources]
SAMPLE=DataDirect DB2 Wire Protocol Driver
**********ADD the below one in END OF THE .odbc.ini FILE**********
[SAMPLE]
Driver=/opt/IBM/InformationServer/Server/branded_odbc/lib/VMdb200.so
Description=DataDirect DB2 Wire Protocol Driver
AddStringToCreateTable=
AlternateID=
Collection=OS/390 and AS/400 (Remove for DB2 UDB)
Database=SAMPLE_1 (Remove for OS/390 and AS/400)
DynamicSections=100
GrantAuthid=PUBLIC
GrantExecute=1
IpAddress=127.0.0.0
IsolationLevel=CURSOR_STABILITY
Location=OS/390 and AS/400 (Remove for DB2 UDB)
LogonID=
Password=
Package=DB2 package name
PackageOwner=
TcpPort=60000
WithHold=1
AuthenticationMethod=1
Step3:
Locate the "uvodbc.config" file in DSEngine Folder
change the below code to config the ODBC database and add it in the "uvodbc.conf
ig" file
<SAMPLE>
DBMSTYPE = ODBC
troubleshoot ODBC connectivity errors in DataStage:
===================================================
To troubleshoot ODBC connectivity problems please follow these steps in sequenti
al order.
1) Test access to database libraries and odbc drivers outside of DataStage
The first step to troubleshoot an ODBC connectivity error is to validate that Da
taStage can successfully load the libraries that the ODBC drivers need to connec
t to a database. The access to these libraries is configured in the file $DSHOME
/dsenv which DataStage sources every time the Engine is started.

Note: Please be aware that changes in this file are not reflected in DataStage u
ntil the Engine is restarted.
To test access to these libraries
a) Open a telnet session with the machine where the DataStage Engine is running
and log as the same user that is trying to connect in DataStage. Then source the
dsenv file by going to $DSHOME and executing:
this will set the environment variable $ODBCINI (that points to the .odbc.ini co
ntaining the Datasource Names (DSN) and the path to the odbc drivers. This also
will set the environment variable $PATH and the library path (the name of this v
ariable depends on the platform the most common ones are LIBPATH and LD_LIBRARY_
PATH).
b) Then you need to identify the driver you are using in your DSN. This can be o
btained by inspecting the .odbc.ini file. Each DSN has a line that starts with "
Driver=" and then the full path to the odbc driver used. For example in this DSN
:
[iadb]
Driver=/opt/IBM/InformationServer/Server/branded_odbc/lib/VMdb222.so
Description=DataDirect DB2 Wire Protocol Driver
Database=iadb
DynamicSections=100
GrantAuthid=PUBLIC
GrantExecute=1
IpAddress=localhost
IsolationLevel=CURSOR_STABILITY
Package=DB2 package name
TcpPort=50000
WithHold=1
the driver is
/opt/IBM/InformationServer/Server/branded_odbc/lib/VMdb222.so
c) Once you have identified this driver you can use the program "ivtestlib" to c
onfirm that you have acess to the libraries that the driver needs. This program
is located under $DSHOME/../branded_odbc/bin, for example to test the driver of
the example, you can run
cd $DSHOME/../branded_odbc/bin
./ivtestlib /opt/IBM/InformationServer/Server/branded_odbc/lib/VMdb222.so
if the libraries are not configured properly you will get one or more lines sayi
ng "Cannot load ...". This is just an example:
exec(): 0509-036 Cannot load program /opt/IBM/InformationServer/Server/branded_o
dbc/lib/VMdb222.so because of the following errors:
0509-022 Cannot load module /opt/IBM/InformationServer/Server/branded_odbc/lib/V
Mdb222.so.
0509-150 Dependent module libVMicu22.a(VMicu22.so) could not be loaded.
0509-022 Cannot load module libVMicu22.a(VMicu22.so).
0509-026 System error: A file or directory in the path name does not exist.
0509-022 Cannot load module /opt/IBM/InformationServer/Server/branded_odbc/lib/V
Mdb222.so.
0509-150 Dependent module /opt/IBM/InformationServer/Server/branded_odbc/lib/VMd

b222.so could not be loaded.

if you get a result like this, then the odbc driver is not accessing the librari
es it needs. To fix this problem you need to edit the file $DSHOME/dsenv and mak
e sure that all the environment variables for this driver are properly set and t
hat this user has proper access to these files. Note: Some databases may require
the user to be part of a particular group for the user to access the libraries.
Check with your DBA if necessary.
If you change the dsenv you should source it and run this test again until ivtes
tlib works successfully. A successful execution of ivtestlib will show the versi
on of the driver. This is an example:
Load of /opt/IBM/InformationServer/Server/branded_odbc/lib/VMdb222.so successful
, qehandle is 0x3
File version: 05.20.0057 (b0034, u0022)
Note: When you source the dsenv file some variables like PATH and LIBPATH append
new values to the existing value of the variables as opposed to replacing the e
ntire value. As result of this, if you source dsenv multiple times in the same s
ession you can end up with long values for these variables and this can cause so
me library conflicts. This won't affect DataStage but can alter the results of y
our test, so if you modify the settings for these variables in dsenv, it is a go
od idea to start a brand new telnet session to make sure you are not inheriting
unneeded values in these variables.
2) Test connection outside of DataStage
After you have confirmed that ivtestlib is working successfully following the in
structions in previous step then you can continue to check if the DSN is properl
y configured. To do this you can use the program "example". The location of this
program varies depending what version of DataStage you are using. It can be fou
nd under either $DSHOME/branded_odbc/example or $DSHOME/branded_odbc/samples.exa
mple.
Note: You might need to change the permissions of this file to make it executabl
e.
Assuming that you have source dsenv already then run:
cd $DSHOME/branded_odbc/samples/example
./example
This program will prompt you for a DSN, a user and a password. The DSN can be ob
tained from the file $DSHOME/.odbc.ini. Continuing with the previous example, th
e DSN to enter would be "iadb". Then it will ask for a database user and passwor
d. If example establishes a successful connection it will show:
Enter SQL statements (Press ENTER to QUIT)
SQL>
If any other message is shown here and the prompt SQL> never appears then this i
ndicates that there is a problem in the DSN configuration. Review the documentat
ion about this driver. A guide with all parameters needed for each driver can be
found under /branded_odbc/books/odbc/odbcuser
3) Test connection in DataStage
After you have have successfully tested the DSN using the programs ivtestlib and
example then you can continue with DataStage. The only additional file that you

DataStage uses besides the .odbc.ini file for ODBC connections is the uvodbc.co
nfig file. There is one uvodbc.config file under each project and it has a list
of all the DSN that can be accessed from this project. Instructions on how to mo
dify this file are located in the same file. Here is an excerpt of this file:
***
***
***
***
***
***

To get to any ODBC source other than UniVerse, you need entries
that look as follows (the data source must also be configured
via the operating system's own mechanisms):
<data source name>
DBMSTYPE = ODBC

A common errors while editing this file are suppressing spaces around the "=". I
n the previous example, you should add these lines to this file:
<iadb>
DBMSTYPE = ODBC
Note: there is also an uvodbc.config file under $DSHOME. This file has the same
structure as that under each project. DSNs added to this file will show up in al
l projects.
The final test is to try to import a table from this database by using Designer
and the ODBC DSN. You should be able to see the DSN listed. If you don't see the
DSN, then there is a problem in the uvodbc.config file. If you see the DSN and
you can get the list of tables of this database then the connection is working f
ine and you can use this DSN in a job.
********************************************************************************
********************************************************************************
********************************************************************************
********************************************************************************
**
In DataStage Designer, an error 'Specified security mechanism, (Unknown), is not
supported by server' occurs when trying to connect via ODBC connector to a DB2
database
Problem(Abstract)
In Designer, when testing a connection to a DB2 database within the ODBC connect
or, the following error occurred.
ODBC function "SQL Connect" reported: SQLSTATE = HY000: Natvie Error Code = 8,33
9: Msg = [IBM(DataDirect OEM)][ODBC DB2 Wire Protocol driver]Specified security
mechanism, (Unknown), is not supported by server.
Diagnosing the problem
In the DataDirect ODBC User's Guide:
AuthenticationMethod (AM)
Description
Specifies the method the driver uses to authenticate the user to the server when
a connection is established. If the specified authentication method is not supp
orted by the database server, the connection fails and the driver generates an e
rror.
Valid Values
0 | 1 | 2 | 3 | 4 | 7 | 8
If set to 0 (No Encryption), the driver sends the user ID and password in cl

ear text to the server for authentication.

If set to 1 (Encrypt Password), the driver sends the user ID in clear text a
nd an encrypted password to the server for authentication.
If set to 2 (Encrypt UID and Password), the driver sends an encrypted user I
D and password to the server for authentication.
If set to 3 (Client Authentication), the driver uses client authentication w
hen establishing a connection. The database server relies on the client to authe
nticate the user and does not provide additional authentication.
If set to 4 (Kerberos Authentication), the driver uses Kerberos authenticati
on. This method supports both Windows Active Directory Kerberos and MIT Kerberos
environments.
If set to 7 (Encrypted Password AES), the driver encrypts the password with
256-bit AES encryption in the connection request. (DB2 V9.7 and higher only.)
If set to 8 (Encrypted UID and Password AES), the driver encrypts the user i
d and password with 256-bit AES encryption in the connection request. (DB2 V9.7
and higher only.)
NOTE: The use of AES encryption (values 7 and 8) requires that the DataDirec
t OpenSSL library be installed.
Default
0 (No Encryption)
Resolving the problem
To resolve the issue, follow the steps below.
Check to see what Database manager authentication is set to:
As the DB2 instance owner, issue the command,
************************
db2 get dbm cfg
************************
Check the entry, Database manager authentication (AUTHENTICATION) to see wha
t it is set to (for example, SERVER_ENCRYPT, SERVER, KERBEROS etc)
Edit the .odbc.ini file:
Change directory to /InformationServer/Server/DSEngine and edit the .odbc.in
i file
Locate the data source that is being used in the job
Add the parameter, AuthenticationMethod to the bottom of the data source nam
e.
If DB2 is using Database manager authentication (AUTHENTICATION) = SERVER_EN
CRYPT, set the parameter, AuthenticationMethod=2
If DB2 is using Database manager authentication (AUTHENTICATION) = SERVER, p
lease set parameter AuthenticationMethod=1
Bind the data source:
Change directory to /InformationServer/Server/DSEngine and source the dsenv
file (ie. . ./dsenv)
Change directory to /IBM/InformationServer/Server/branded_odbc/bin directory
As the DB2 instance owner, run the command:

./bind25 <data source name>

Retry the connection to the database