The DB2 ODBC Environment | DB2(R) Universal Database for OS/390 V7.1 Application Certification Guide (IBM DB2 Certification Guide Series)


Team-Fly

	DB2 Universal Database for OS/390 v7.1 Application Certification Guide By Susan Lawson
	Table of Contents

	Chapter 11. ODBC/CLI Programming

The DB2 ODBC Environment

DB2 for OS/390 and z/OS does not support an ODBC driver manager. All API calls are routed through the single ODBC driver that is loaded at runtime into the application address space. DB2 ODBC support is implemented as an IBM C/C++ dynamic load library (DLL). By providing DB2 ODBC support using a DLL, DB2 ODBC applications do not need to link-edit any DB2 ODBC driver code with the application load module. Instead, the linkage to the DB2 ODBC APIs is resolved dynamically at runtime by the IBM Language Environment (LE) runtime support. The DB2 ODBC driver can use either the call attachment facility (CAF) or the Recoverable Resource Manager Services attachment facility (RRSAF) to connect to the DB2 for OS/390 and z/OS address space.

If the DB2 ODBC application is not running as a stored procedure, the MVSATTACHTYPE keyword in the DB2 ODBC initialization file determines the attachment facility that DB2 ODBC uses.
If the DB2 ODBC application is running as a stored procedure, then DB2 ODBC uses the attachment facility that was specified for stored procedures.

When the DB2 ODBC application invokes the first ODBC function, SQLAllocHandle(), to allocate the environment handle, the DB2 ODBC driver DLL is loaded.

DB2 ODBC supports access to the local DB2 for OS/390 and z/OS subsystems and any remote data source that is accessible using DB2 for OS/390 and z/OS Version 7. These include

Remote DB2 subsystems using specification of an alias or three-part name
Remote DRDA-1 and DRDA-2 servers using LU 6.2 or TCP/IP

There are several DB2 ODBC packages that must be bound at each possible data source, including the local DB2 for OS/390 and z/OS subsystem and all remote DRDA application servers. This task must be completed before an ODBC program can successfully use a data source.

Initialization File

DB2 ODBC uses an optional initialization file to retrieve default settings for configuration options and attributes. For most applications, the use of this file may not be necessary. The initialization file is specified at runtime by a DSNAOINI DD statement in the JCL that executes the program. UNIX System Services programs specify the initialization file using the DSNAOINI environment variable.

The initialization file is divided into three sections. The common section contains parameters that are global to all data sources. The subsystem section contains parameters that are specific to a DB2 subsystem. The data source section contains parameters specific to a data source. Within each section are keyword and value pairs that set the option values. A possible example of an initialization file follows .

 ; This is a comment line...  ; Common Section, set default subsystem [COMMON] MVSDEFAULTSSID=DSN1 ; DSN1 subsystem settings [DSN1] MVSATTACHTYPE=CAF PLANNAME=DSNACLI ; DB2CERT Data Source [DB2CERT] AUTOCOMMIT=0 CONNECTTYPE=2 SCHEMALIST="'DB2USER1'"

When the environment handle is allocated, the MVSDEFAULTSSID is used to connect to the DB2 for OS/390 and z/OS address space. This is the subsystem where the DB2 location names of the data sources must be known. Data sources correspond to DB2 location names as defined in the SYSIBM.LOCATIONS table in the communications database. The local database name is the name that was set during DB2 installation. If a null connection is made, the local subsystem will act as the data source, so using null connections and different initialization files is an easy way to point an ODBC program at a different subsystem. Each instance of a program executing DB2 ODBC could potentially have its own initialization file.


Team-Fly

Top