The Target Database tab enables the user to configure required, as well as optional, attributes used to define the target DB2 system.
For the Microsoft® ODBC Driver for DB2 in Host Integration Server 2004, the Target Database tab has the following fields.
|Initial catalog||This parameter is used as the first part of a three-part fully qualified DB2 table name. It is referred to by different names depending on the DB2 platform.
In DB2 for OS/390 and DB2 for MVS, this parameter is referred to as LOCATION. The SYSIBM.LOCATIONS table lists all the accessible locations. To find the location of the DB2 that you need to connect to on these platforms, ask the administrator to look in the TSO Clist DSNTINST under the DDF definitions. These definitions are provided in the DSNTIPR panel in the DB2 Installation Manual.
In DB2/400 on OS/400, this property is referred to as RDBNAM. The RDBNAM value can be determined by invoking the WRKRDBDIRE command from the console to the OS/400 system. If there is no RDBNAM value, a value can be created using the Add option.
In DB2 Universal Database, this property is referred to as DATABASE.
|Package collection||The name of the DRDA target collection (AS/400 library) where the Microsoft ODBC Driver for DB2 should store and bind DB2 packages. This can be the same as the default schema.
The ODBC Driver for DB2, which is implemented as an IBM DRDA application requester, uses packages to issue dynamic and static SQL statements. The ODBC driver creates packages dynamically in the location that the user points to using the Package Collection parameter.
By default, the ODBC Driver for DB2 automatically creates one package in the target collection, if one does not exist, at the time the user issues the first SQL statement. The package is created with GRANT EXECUTE authority to a single <AUTH_ID> only, where AUTH_ID is based on the user ID value configured in the data source. The package is created for use by SQL statements issued under the same isolation level based on the Isolation Level value specified in the connection.
Problems can arise in multi-user environments. For example, if a user specifies a Package Collection value that represents a DB2 collection used by multiple users, but this user does not have authority to GRANT execute rights to the packages to other users (the PUBLIC group on the DB2 system, for example), the package is created only for use by this user. This means that other users may be unable to access the required package. The solution is for an administrative user with package administrative rights to create a set of packages for use by all users. (For more information, see Creating Packages for Use with the ODBC Driver for DB2.)
The ODBC Driver for DB2 supplied with Host Integration Server 2004 includes the Data Access Tool for use by administrators to create packages. This tool can be run using a privileged User ID to create packages in collections accessed by multiple users. This tool will create a set of packages and grant EXECUTE privilege on these packages to the PUBLIC group representing all users on the DB2 system. The packages (see descriptions under the SQL_ATTR_TXN_ISOLATION connection attribute) created are as follows:
AUTOCOMMITTED package (MSNC001 is only applicable on DB2/400)
Note that the AUTOCOMMITTED package (MSNC001) is only created on DB2 for OS/400.
Once created, the packages are listed in the DB2 (mainframe) SYSIBM.SYSPACKAGE, the DB2 for OS/400 QSYS2.SYSPACKAGE, and the DB2 Universal Database (UDB) SYSIBM.SYSPACKAGE catalog tables.
Note that when upgrading from SNA Server 4.0, any existing SNA Server 4.0 packages must be re-created using the Host Integration Server Data Access Tool to make them compatible with Host Integration Server 2004. The package names changed from SNA Server 4.0.
|Default Schema||The name of the collection where the ODBC Driver for DB2 looks for catalog information. Default schema is the SCHEMA name for the target collection of tables and views. The ODBC driver uses the Default Schema to restrict results sets for popular operations, such as enumerating a list of tables in a target collection (for example, ODBC Catalog SQLTables).
For DB2, the Default Schema is the target AUTHENTICATION (User ID or owner).
For DB2/400, the Default Schema is the target COLLECTION name.
For DB2 Universal Database (UDB), the Default Schema is the SCHEMA name.
If the user does not provide a value for Default Schema, the ODBC driver uses the USER_ID provided at log on. For DB2/400, the driver uses QSYS2 if no collection is found matching the USER_ID value. This default is inappropriate in many cases so it is essential that the Default Schema value in the data source be defined.
|DBMS Platform||The target DB2 platform property value is used to optimize performance of the ODBC driver when executing operations such as data conversion. The default value is DB2/MVS.|
|Default Qualifier||The name of the schema (collection/owner) with which to fully qualify unqualified object names. This attribute enables the user to access database objects without fully qualifying the objects using a collection (schema) qualifier. The ODBC driver sends this value to DB2 using a SET CURRENT SQLID statement, instructing the DBMS to use this value when locating unqualified objects (for example, tables and views) referenced in SQL statements. If you do not set a value for the default qualifier, no SET statement is issued by the ODBC driver. This ODBC connection attribute is only valid when connecting to DB2 for MVS (OS/390, z/OS).|
|Alternate TP Name||The Alternate Transaction Program (TP) Name property represents the default transaction program name for the DB2 DRDA application server (AS), which is 07F6DB (DB2DRDA). However, some DB2 installations may be configured to use an alternate TP name.
Host Integration Server 2004 uses the Alternate TP Name in the offline demo configuration (DRDADEMO.UDL). In that case, the Alternative TP Name is set to 0X07F9F9F9.
|Distributed transactions||When this option is checked, two-phase commit (distributed unit of work) is enabled. Distributed transactions are handled using Microsoft Transaction Server, Microsoft Distributed Transaction Coordinator, and the Host Integration Server 2004 Resync Service.|
|Process binary as character||When this option is checked, it indicates that binary data fields should be processed as characters. This option treats binary data type fields (with a CCSID of 65535) as character data type fields on a per-data source basis. The Host CCSID and PC Code Page values are required input and output parameters. For more information, see the Locale tab.|
All rights reserved.