In tandem with the announcement of its new z990 “T-Rex” mainframe systems, IBM Corp. Each instance of a program executing DB2 ODBC could potentially have its own initialization file.64-bit DB2 for z/OS. 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. The local database name is the name that was set during DB2 installation. Data sources correspond to DB2 location names as defined in the SYSIBM.LOCATIONS table in the communications database. This is the subsystem where the DB2 location names of the data sources must be known. When the environment handle is allocated, the MVSDEFAULTSSID is used to connect to the DB2 for OS/390 and z/OS address space. Common Section, set default subsystem MVSDEFAULTSSID=DSN1 DSN1 subsystem settings MVSATTACHTYPE=CAF PLANNAME=DSNACLI DB2CERT Data Source AUTOCOMMIT=0 CONNECTTYPE=2 SCHEMALIST="'DB2USER1'" A possible example of an initialization file follows. Within each section are keyword and value pairs that set the option values. The data source section contains parameters specific to a data source. The subsystem section contains parameters that are specific to a DB2 subsystem. The common section contains parameters that are global to all data sources. The initialization file is divided into three sections. UNIX System Services programs specify the initialization file using the DSNAOINI environment variable. The initialization file is specified at runtime by a DSNAOINI DD statement in the JCL that executes the program. For most applications, the use of this file may not be necessary. Initialization FileĭB2 ODBC uses an optional initialization file to retrieve default settings for configuration options and attributes. This task must be completed before an ODBC program can successfully use a data source. 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. Remote DRDA-1 and DRDA-2 servers using LU 6.2 or TCP/IP Remote DB2 subsystems using specification of an alias or three-part name When the DB2 ODBC application invokes the first ODBC function, SQLAllocHandle(), to allocate the environment handle, the DB2 ODBC driver DLL is loaded.ĭB2 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. If the DB2 ODBC application is running as a stored procedure, then DB2 ODBC uses the attachment facility that was specified for stored procedures. 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. 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. Instead, the linkage to the DB2 ODBC APIs is resolved dynamically at runtime by the IBM Language Environment (LE) runtime support. 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. DB2 ODBC support is implemented as an IBM C/C++ dynamic load library (DLL). All API calls are routed through the single ODBC driver that is loaded at runtime into the application address space. DB2 Universal Database for OS/390 v7.1 Application Certification GuideĭB2 for OS/390 and z/OS does not support an ODBC driver manager.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |