< Day Day Up > |
In order for DRDA to exist, it relies upon other established protocols (see Figure 41.2). These architectures are examined in the following sections. Figure 41.2. DRDA's supporting architectures.
Advanced Program-to-Program CommunicationAdvanced Program-to-Program Communication (APPC) provides peer-level communication support based on LU 6.2 protocols. LU 6.2 is an advanced communication architecture that defines the formats and protocols for communication between functionally equivalent logical units. APPC/LU 6.2 provides communication and transaction processing facilities needed for cooperative processing and distributed transaction processing. Distributed Data ManagementThe Distributed Data Management (DDM) architecture defines facilities for accessing distributed data across a network using APPC and LU 6.2. With DDM, the distributed data to be accessed can reside in either files or relational databases. An RDBMS is implied , however, within the context of DRDA. Formatted Data: Object Content ArchitectureFD:OCA is an architecture that provides for the distribution and exchange of field-formatted data. Using FD:OCA, both the data and its description are packaged together so that any DRDA-compliant DBMS can understand its structure and content. Character Data Representation ArchitectureCharacter Data Representation Architecture (CDRA) is the architecture utilized to ensure that any symbol or character used on any SAA relational DBMS has the same meaning regardless of the underlying coded character set. CDRA provides a method of unambiguously identifying data from any SAA platform. CDRA is necessary particularly when data is transferred between a PC workstation (using ASCII code) and a mainframe (using EBCDIC code). Theoretically, CDRA can be extended to support other codes (such as Unicode, a new character encoding scheme gaining support). |
< Day Day Up > |