< Day Day Up > |
DB2 can distribute data following three of the DRDA levels: remote request, remote unit of work, and distributed unit of work. As of DB2 V6, distributed request capability is not available. Additionally, DB2 V6 supports application requester and application server functions. The database server function is not available under DB2 V6. DB2 also provides the capability to access distributed data using a non-DRDA private protocol. This capability was introduced to DB2 prior to the existence of DRDA. The BasicsThe Distributed Data Facility (DDF) is required for accessing distributed data through DB2. The DDF is an optional DB2 address space. Recall from Chapter 20, "DB2 Behind the Scenes," that the other address spaces are the DBAS, SSAS, and IRLM, as well as optional stored procedure address spaces using WLM. The Communication DatabaseDistributed DB2 connections are defined using system tables defined to DB2. Connection information is stored in the DB2 Catalog in the Communications Data Base tables, or CDB. The DDF reads the CDB to perform authid name translations and to map DB2 objects to VTAM objects. The CDB exists in a separate table space in the DB2 Catalog, named SYSDDF . In a distributed environment, each DB2 subsystem is identified by a unique location name of up to 16 characters . A location can be explicitly accessed using CONNECT or three-part table names . CAUTION
There are seven CDB tables stored in a single table space ( SYSDDF ):
Distributed TermsIn addition to the DRDA terms from the preceding chapter, I use the following terms in the remainder of this chapter:
In the remainder of this chapter, I describe the data distribution options that exist for DB2 for z/OS and OS/390. |
< Day Day Up > |