DRDA defines types of distributed database management system functions. DB2 for OS/390 Version 5 supports remote unit of work. With remote unit of work, an application program executing in one system can access data at a remote DBMS using the SQL provided by that remote DBMS.
DB2 for OS/390 Version 5 also supports distributed unit of work. With distributed unit of work, an application program executing in one system can access data at multiple remote DBMSs using SQL provided by remote DBMSs. For more information on the types of distribution defined by DRDA, see DRDA Connectivity Guide.
As shown in Figure 14, DB2 for OS/390 supports three configurations of distributed database connections using two access methods:
[1] System-directed access (also known as using DB2 for OS/390 private protocol) allows a DB2 for OS/390 requester to connect to one or more DB2 for OS/390 servers. The connection established between the DB2 for OS/390 requester and server does not adhere to the protocols defined in DRDA and cannot be used to connect non-DB2 for OS/390 products to DB2 for OS/390. This type of connection is established by coding three-part names or aliases in the application.
[2] Application-directed access allows a DB2 for OS/390 or non-DB2 for OS/390 requester to connect to one or more DB2 for OS/390 or non-DB2 for OS/390 application servers using DRDA protocols. The number of application servers that can be connected to the application requester at one time depends on the level of DB2 for OS/390 of the application requester. If the application requester is DB2 for MVS/ESA V2R3, then only one application server can be connected at a time. This type of connection is established by coding SQL CONNECT statements in the application. If the application requester is DB2 for MVS/ESA V3R1, or DB2 for OS/390 V5R1, then one or more application servers can be connected at a time.
[3] Application-directed and system-directed access can be used together to establish connections. You cannot connect using DRDA and system-directed storage in the same thread.
The term secondary server describes systems acting as servers to the application server.
If all systems in a configuration support two-phase commit, then distributed unit of work (multiple-site read and multiple-site update) is supported. If not all systems support two-phase commit, updates within a unit of work are either restricted to a single site that does not support two-phase commit, or to the subset of sites that support two-phase commit.
Figure 14. DB2 for OS/390 Distributed Connections
Table 2 compares the DB2 for OS/390 distributed database connection types.
Table 2. Comparison of DB2 for OS/390 Distributed Database Connections
| [1] System-Directed Access | [2] Application-Directed Access (with all systems having two-phase commit) | [3] Application-Directed and System-Directed Accesses |
|---|---|---|
| All partners must be DB2 for OS/390 systems | Can interconnect any two DRDA systems | Application requester can be any DRDA system; servers must be DB2 for OS/390 systems |
| Can connect directly to many partners | Can connect directly to many partners | Application requester connects directly to Application Servers; Application Servers can connect to many DB2 for OS/390 secondary servers |
| Each SQL application can have multiple conversations with each server | Each SQL application has one conversation with each server | SQL application has one conversation with each server; DB2 for OS/390 application server can establish many conversations to each server for the application |
| Can access both local and remote resources in one commit scope | Can access both local and remote resources in one commit scope | Application requester and Application Server can access local and remote data |
| More efficient at large queries and multiple concurrent queries | More efficient at SQL statements that are executed very few times in one commit scope | Application requester-Application Server connection behaves like [2]; secondary server connections behave like [1] |
| Can support static or dynamic SQL, but server dynamically binds static SQL the first time it is executed in a commit scope | Can issue static or dynamic SQL | Application requester and Application Server can issue static or dynamic SQL; secondary servers support static or dynamic SQL, but dynamically bind static SQL the first time it is executed in a commit scope |
| Limited to SQL INSERT, DELETE, and UPDATE statements, and to statements that support SELECT | Can use any statement supported by the system that executes the statement | Application servers supports any SQL; secondary servers support only DML SQL (for example, CREATE or ALTER) |
Until DB2 for OS/390 Version 5.1, connect requests that provided user IDs or passwords could fail with SQL30082 reason code 0, but no other indication as to what might be wrong.
DB2 for OS/390 Version 5.1 introduces an enhancement which provides support for extended security codes. Specifying extended security will provide additional diagnostics, such as (PASSWORD EXPIRED) in addition to the reason code.
In order to exploit this, the DB2 for OS/390 ZPARM installation parameter for extended security should be set to the value YES. Use the DB2 for OS/390 installation panel DSN6SYSP to set EXTSEC=YES. You can also use DDF panel 1 (DSNTIPR) to set this. The default value is EXTSEC=NO.
If you wish to provide support for the DB2 Universal Database security option AUTHENTICATION=CLIENT, then use DB2 for OS/390 installation panel DSNTIP4 (DDF panel 2) to set TCP/IP already verified security to YES.
ODBC applications use dynamic SQL. This may create security concerns in some installations. DB2 for OS/390 introduces a new bind option DYNAMICRULES(BIND) that allows execution of dynamic SQL under the authorization of either the owner or the binder.
DB2 Universal Database Version 5.0 provides a new CLI/ODBC configuration parameter CURRENTPACKAGESET in the DB2CLI.INI configuration file. This should be set to a schema name that has the appropriate privileges. An SQL SET CURRENT PACKAGESET schema statement will automatically be issued after every connect for the application.
Use the ODBC Manager to update DB2CLI.INI. See Installing and Configuring DB2 Clients for further information.