Distributed Data Management Architecture

Distributed Data Management Architecture (DDM)
Company type	Software architecture
Industry	Information technology
Founded	1980
Founder	Richard A. Demers, Kenneth Lawrence, Richard Sanders
Headquarters	Rochester, United States
Products	Distributed data management framework, messaging formats, protocols

Distributed Data Management Architecture (DDM) represents IBM's openly documented software architecture designed to facilitate the creation, administration, and retrieval of data located on remote systems. Originally intended for record-oriented files, DDM's scope broadened to encompass hierarchical directories, stream-based files, queues, system command execution, and ultimately served as the basis for IBM's Distributed Relational Database Architecture. It also includes mechanisms for data description and transformation. Developed over the period from 1980 to 1993, DDM specifies components, messaging structures, and protocols grounded in object-oriented design principles.

Rather than being a software product itself, DDM functions as a framework implemented through client and server software solutions. As an open standard, implementations may adopt partial subsets or extend the architecture to fulfill particular requirements. Together, these implementations provide the foundation for a distributed file system.

Distributed applications

Creating distributed applications requires strategic placement of programs and data, considering factors such as data volume, communication frequency, management complexity, security requirements, and response time. Three dominant client–server models inform this approach:

The File Transfer Protocol (FTP) model involves transferring entire files or database tables to clients for local processing. This is ideal for highly interactive programs like word processors or spreadsheets where minimal sharing occurs.
Thin client architectures centralize processing on servers that maintain files or databases, while clients primarily provide user interfaces. Interaction between client and server employs remote procedure calls, with defined messages specifying procedures, parameters, and results.
Fat client systems distribute processing tasks to clients but retain centralized data storage on servers to ensure consistent management and up-to-date information. Only modified records or relevant data segments are exchanged over the network. This approach necessitates deploying client software to all users accessing the shared data.

DDM was initially crafted to support the fat client paradigm but also accommodates complete file transfers.

Advantages offered by DDM architecture

The DDM framework delivers several significant benefits to distributed applications:

Transparent local/remote access: Applications can interact with remote data as if it were local without needing specialized coding.
Minimized data duplication: Information is maintained in a single location within the network.
Improved security: Reducing redundant copies enhances control over authorized access.
Data consistency: Simultaneous updates by local and remote users are managed to prevent conflicts.
Up-to-date information availability: Multiple users across different machines access current data.
Efficient resource utilization: Storage and processing capabilities distributed across networks are optimized.

Historical background

The DDM architecture consists of defined message formats and protocols that enable management and access of data spread across networked computers.

Early developments

IBM's original Systems Network Architecture (SNA) linked workstations to mainframes in a hierarchical manner with fixed connections managed by mainframe software. As networking shifted toward flexible peer-to-peer models, IBM introduced Advanced Program-to-Program Communications (APPC) in the early 1980s to support remote operating system services such as file and printer sharing. Despite this progress, development slowed because mainframes were largely regarded as isolated systems and APPC was not widely available on them.

At IBM's Rochester facility, engineers identified business opportunities for distributed services among midrange machines like the IBM System/3, IBM System/34, and IBM System/36. A rudimentary distributed file service named Distributed Data File Facility (DDFF) connected these minicomputers. As multiple IBM System/36 and IBM System/38 units were deployed at customer sites, enabling interaction between central offices and warehouses became essential. Implementing APPC on these systems revived interest in distributed operating system services under the project name Golden Gate. Nevertheless, product managers hesitated to proceed without clearly defined business justifications.

John Bondy, a planner from the Golden Gate initiative, persuaded management to establish a dedicated team focused exclusively on Distributed Data Management (DDM), concentrating initially on record-oriented file support. He enlisted software architect Richard A. Demers to develop the DDM architecture framework and advocate its adoption within IBM's system divisions.

Early development encountered opposition as IBM divisions demanded concrete business cases upfront and preferred message formats aligned with their existing file system interfaces. The emergence of Personal Computers functioning as terminals led some stakeholders to suggest enhancing the 3270 data stream protocol rather than investing in DDM.

During this phase, Demers created a client-server architectural design for DDM featuring generic object-oriented message formats influenced by Smalltalk and the IBM System/38. This approach clarified how DDM could be implemented consistently across heterogeneous systems (refer to How DDM works).

By 1982, planners working with System/36 recognized a promising market opportunity for record-oriented file services based on DDM.

DDM Level 1: Record-Based File Structures

Although the general framework for DDM messages had been established, the precise message types required remained uncertain. The System/36 file system addressed record-based file operations for third-generation programming languages such as Fortran, COBOL, PL/I, and IBM RPG, similar to the System/38 and IBM mainframe’s Virtual Storage Access Method (VSAM). However, these systems offered diverse capabilities and interfaces, prompting the question of which should be incorporated into DDM. Refer to record-oriented files for details.

Early development of DDM by the Golden Gate project followed the abstract File Transfer Access and Management (FTAM) standard for distributed file systems. This approach proved challenging to align with local file services and limited adoption among IBM system vendors. Kenneth Lawrence, architect of System/36 file services, proposed defining messages that could be straightforwardly implemented on at least one IBM platform—namely System/36—and allowing other systems to request enhancements. After a year of limited progress, Lawrence’s method gained acceptance.

Richard Sanders joined forces with Lawrence and Demers to craft DDM messages specific to the System/36 environment. This collaboration drew in System/38 developers, broadening DDM’s support for record-based files to accommodate the more sophisticated requirements of its file system.

Files function within an operating system framework that governs structure, concurrent access, and security protocols. Level 1 DDM did not facilitate remote directory browsing beyond sending fully qualified file names but included necessary security and sharing mechanisms designed by Sanders. He also created communication management protocols incorporated into the DDM Conversational Communications Manager—initially implemented using APPC and later adapted for TCP/IP.

Following completion of System/36 DDM, Lawrence partnered with IBM’s Hursley Park laboratory to repurpose much of its server-side code for the IBM Customer Information Control System transaction processing environment. This enabled CICS to function as a DDM server on MVS and VSE mainframes. Additionally, he collaborated with programmers at IBM Cary laboratory to develop a DDM record-oriented client compatible with IBM PC DOS.

The formal release of Level 1 DDM Architecture occurred in 1986. In recognition of their contributions, IBM honored Kenneth Lawrence with an Outstanding Technical Achievement Award, Richard Sanders with an Outstanding Contribution Award, and Richard Demers with an Outstanding Innovation Award.

For clarity in this article, System/38 encompasses the original System/38 along with its successors: the IBM AS/400 (which combined functionalities of System/36 and System/38), the IBM iSeries, and the IBM Power Series (which integrated iSeries capabilities with IBM RS/6000 UNIX-based servers).

DDM Level 2: Hierarchical Directory Structures and Stream-Based Files

As the prominence of IBM PC and Unix platforms increased within networked environments, DDM expanded its capabilities to include support for hierarchical directory structures and stream-based files on IBM Personal Computer running IBM PC DOS as well as on IBM RS/6000 systems operating under IBM AIX. Consult Stream-oriented files for further information.

Released in 1988, DDM Architecture Level 2 was chiefly developed by Jan Fisher and Sunil Gaitonde to enable functionality for directories and stream-oriented file types.

DDM level 3: Relational database services

By 1986, IBM had introduced four unique relational database (RDB) products, each designed for different IBM operating systems. At IBM Almaden, researchers created System/R*, a prototype distributed RDB system; however, merging this with existing offerings proved difficult.

A cross-product team led by Roger Reinsch at IBM Santa Teresa established the Distributed Relational Database Architecture (DRDA), which included:

Representatives from every IBM RDB product,
Bruce Lindsay, a System/R* researcher,
Paul Roever from IBM Sindelfingen, who developed the Formatted Data: Object Content Architecture (FD:OCA),
Richard Sanders and Richard Demers from the DDM group responsible for models, messaging, and protocols.

In 1990, both DDM Architecture Level 3 and DRDA were released concurrently as integral parts of IBM's Systems Application Architecture (SAA). DRDA became the standard adopted by all four IBM RDB products and external vendors.

Significant contributors were honored: Richard Sanders received an Outstanding Contribution Award, while Roger Reinsch and Richard Demers were granted Outstanding Innovation Awards.

DDM level 4: Additional Services

The Distributed File Management (DFM) initiative incorporated DDM services into IBM's MVS operating system, allowing remote creation and administration of VSAM files. John Hufferd directed the DFM project, with Richard Demers overseeing data field conversion efforts alongside Koichi Yamaguchi. Refer to Data description and conversion for details.

At Level 4, additional services were defined by Richard Sanders, Jan Fisher, and Sunil Gaitonde, including:

Storage management capabilities and user-defined file attributes for DFM,
Two-phase commit protocols to manage distributed transactions in DRDA,
Queues facilitating application-defined records that can be created or managed remotely (DDM Queues),
A System Command Processor to execute host system commands from remote locations,
Multi-tasking Communications Manager supporting multiple client-server agent interactions within a single session,
Sync Point manager coordinating logical units of work across various DDM servers using two-phase commit protocols to ensure resource recovery.

The Level 4 DDM Architecture was published in 1992.

DDM level 5: Library services

The architecture of DDM level 5 introduced support for:

Mainframe Partitioned Data Sets, which are collections of similar files organized with internal directories,
Personal Computer Libraries, enabling unified access to files spread across multiple folders,
Further improvements to DRDA functionality.

Jan Fisher led the development of the DDM level 5 architecture, which was published by the Open Group rather than IBM. Shortly thereafter, IBM dissolved its DDM architecture team.

Inside DDM

The DDM architecture consists of a formally specified, well-structured set of standards. This section highlights fundamental technical principles that form the basis of DDM.

How DDM Operates

DDM establishes a client/server protocol framework where a client solicits services from a server that accesses local resources, subsequently delivering data and status feedback. Within DDM terminology, the client is referred to as a Source Server, while the server is called a Target Server.

Applications access local resources through programming interfaces provided by a local resource manager (LRM). When dealing with remote resources, DDM facilitates this by rerouting LRM calls to a DDM client. The redirection approach varies; for instance, some implementations rely on special local files known as DDM Files that contain information for remote access.
Entities at the manager level oversee files, databases, and access methods. A Client Resource Manager (CRM) supports the client system’s LRM interfaces and creates serialized DDM commands and data objects, which are transmitted to the remote Server Resource Manager (SRM) via DDM client/server Agents and Communications Managers.
The Client Agent wraps commands inside RQSDSS envelopes and data objects within OBJDSS envelopes, establishing communication pathways with the Server Agent. It enables simultaneous interactions with multiple remote resources across diverse systems by routing messages through distinct virtual channels.
Both Client and Server Communications Managers implement a conversational protocol—characterized by an "I speak while you listen" exchange—utilizing protocols such as IBM’s SNA APPC or TCP/IP.
Upon receiving messages, the Server Agent directs them to the SRM along designated paths, managing numerous clients and communication routes as required.
The SRM interprets incoming messages, executes requested operations through the server’s LRM interfaces, then assembles data and status responses into serialized objects and reply messages for the Server Agent.
The Server Agent encapsulates replies within RPYDSS and OBJDSS envelopes and transmits them back via Communications Managers to the Client Agent.
Finally, the Client Agent extracts responses from these envelopes and forwards them to the CRM, which translates replies back into the original LRM interface format for use by the application.

This well-defined protocol ensures seamless access to remote resources while preserving local programming interface consistency.

Object-Orientation

The design of DDM follows an object-oriented paradigm. Every component within DDM is an object characterized by self-describing Class objects. Messages, replies, and data exchanged across systems are serialized objects that specify their length, class via a DDM codepoint, and data content as dictated by their class definitions. Each class also delineates commands applicable to its instances within DDM clients or servers, encapsulating objects with a restricted set of operations.

DDM’s structure comprises hierarchical object layers exhibiting emergent properties at higher levels:

A field represents a sequence of bits encoding numbers, characters, or other data types. Instances derived from Field subclasses are encapsulated through class-defined operations such as arithmetic on integer fields.
An object is a self-identifying entity composed of one or more fields enclosed by defined operations. Drawing inspiration from Smalltalk kernel object classes:
- Scalar objects contain a single field serving as parameters in commands and replies or as attribute values like length; their encoding is fully specified by DDM.
- Mapped objects consist of multiple fields (such as application-defined records), with encoding and alignment determined by application declarations and programming languages rather than DDM itself.
- Collection objects act as containers for other objects; examples include DDM Commands and Replies.
A manager offers an environment for storing and processing objects encapsulated by its class-specific operations. Collections of managers form the processing environment within DDM clients or servers. Examples include Dictionary, Supervisor, Agent, Directory, File(s), Access Method(s), Relational Database, SQL Application Manager, Queue, Lock Manager, Security Manager, Recovery Manager, System Command Processor, and Communication Manager(s).
A server functions as an entity hosting managers responsible for storage and processing in distributed settings—for example, clients or servers specialized in distributed file or relational database management.

While DDM’s architecture is inherently object-oriented, its implementations utilized host system languages and techniques. Notably, Object Technology International developed a Smalltalk version for the IBM PC that generated Smalltalk classes directly from the DDM Reference Manual.

Subsets and Extensions

DDM is designed as an open framework, enabling products to implement specific subsets or develop their own custom extensions.

The DDM command Exchange Server Attributes establishes client-server communication by identifying the client, declaring the required managers, and indicating the supported DDM level. The server responds by specifying its supported level. Typically, a product that supports Level X of a DDM manager must also support Level X-1 to maintain compatibility between newer servers and legacy clients.

DDM subsets can be customized based on product requirements:

they may be client-only (such as DDM/PC), server-only (like CICS/DDM), or support both roles (for example, System/38 DDM).
subsets can target particular managers such as record-oriented files, stream files, or relational databases through DRDA; for instance, MVS Database 2 implements only the DRDA-mandated DDM subset.
they may include selected commands within a manager, for example commands related to loading or unloading sequential file records.
support can be limited to specific command parameters, such as the 'Return Inactive Records' option in the 'Get Record' command.

When connecting known client-server pairs (e.g., System/38), DDM allows extensions by incorporating:

new managers tailored to specific products,
additional commands within existing managers,
new parameters added to commands or their replies.

These enhancements integrate seamlessly into DDM’s object-oriented design, utilizing existing message processing mechanisms.

DDM Messages

Within DDM’s object-oriented architecture, clients, servers, managers, and objects reside in memory linked via pointers. However, commands must be transmitted as serialized bit streams rather than memory pointers. The in-memory command structure includes total size, a class pointer, and parameter pointers; when linearized for transmission, it consists of total length, a class code point, and serialized parameters. Each object class—covering commands, records, and replies—is uniquely identified by a code point across all transmitted objects.

Serialized objects are encapsulated within Data Stream Structures (DSS) to facilitate coordination between client and server agents. Commands are wrapped in Request DSS (RQSDSS), replies in Reply DSS (RPYDSS), while other objects utilize Object DSS (OBJDSS). Each RQSDSS or RPYDSS carries a single command or reply respectively; OBJDSSes may contain multiple records or objects. OBJDSSes can be chained to RQSDSS or RPYDSS structures to manage large volumes of data. A DSS includes fields for total length, a type flag byte, a request identifier linking related DSS units—such as pairing client requests with server responses—and the enclosed serialized objects.

Documentation

The DDM Reference Manual is composed of named Menu, Help, and Class objects. Subclasses of the DDM base class Class are defined through variables that specify their superclass, creating an inheritance hierarchy; for example, Record File is derived from File, which itself inherits data and commands from Manager. Each class is self-describing via class commands and class variables, which encompass:

a concise title,
the class’s development status within DDM,
explanatory text and diagrams illustrating the class's relationship to its components and environment,
encapsulated data elements such as Fields, Objects, and Managers,
applicable commands for instances of the class.

These objects reference other named entities within textual descriptions and specifications, establishing hypertext links throughout the manual. Menu and Help pages deliver an integrated tutorial on DDM concepts. The printed manual exceeds 1400 pages and is unwieldy; consequently, an interactive version was created for internal IBM use—primarily at the Rochester laboratory—due to limitations in communication speeds.

Alongside the Reference Manual, additional documentation includes a General Information document aimed at executive audiences providing high-level insights into DDM, as well as a Programmer’s Guide summarizing core concepts for developers working on clients and servers.

DDM file models

The DDM framework specifies three distinct file models: record-oriented files, stream-oriented files, and hierarchical directory structures.

Essential remote file management functionalities encompass:

creating, clearing, and deleting files,
copying, loading, and unloading file contents,
locking and unlocking files,
retrieving and modifying file attributes.

Record-oriented files

Tailored for third-generation languages such as Fortran, Cobol, PL/I, and RPG, record-oriented files facilitate standardized data input/output and storage operations within operating environments.

A record represents a sequence of related data fields encoded contiguously as bytes—for instance, employee details like name, address, ID number, and salary. Initial implementations processed records sequentially using punched cards or tapes; later advancements allowed random access by key fields or record position. Records may be uniform in format (e.g., payroll data) or heterogeneous (e.g., event logs), with some files designated as read-only while others permit updates.

Within DDM's record-oriented file model, attributes include creation timestamp, last modification date, record length, and storage slots. Record lengths can be fixed or variable based on the underlying storage medium. DDM categorizes four types:

Sequential files: records arranged one after another.
Direct files: records stored in slots determined by a specific field value.
Keyed files: sequentially stored records with a secondary ordering maintained through key field indexes.
Alternate index files: separate key field indexes built upon existing sequential, direct, or keyed files.

DDM further defines multiple access methods for handling record-oriented files. An access method instance initiates file interaction via an OPEN command following authorization checks and terminates with a CLOSE command.

Each access method manages a cursor indicating the current record position. SET commands reposition this cursor to the beginning or end of the file, the next or previous sequential record, a particular key-based record, or adjacent keyed records.

Several access methods may simultaneously open the same file for different clients. To prevent conflicts during update operations, locks are implemented at either the file or record level: opening a file for update locks the entire file; reading a record locks that record until it is updated and unlocked; other clients must wait until the lock is released.

Stream-oriented files

Stream-oriented files consist of an uninterrupted sequence of bytes that allows applications to flexibly map their data structures. This model predominates in Unix, Unix-like systems, and Windows. DDM specifies a single stream file model along with its corresponding access method.

Attributes of the DDM stream file model include creation date and total stream length. The continuous byte sequence is accessed via the Stream Access Method. Applications can write data at arbitrary locations within the stream while managing positions independently. For example, document streams are managed by programs like Microsoft Word, whereas spreadsheet streams are handled by applications such as Microsoft Excel.

A Stream access method instance serves only one client at a time and uses a cursor to track the current byte offset. SET commands move this cursor to the start or end of the stream or to specific positions or relative offsets.

Multiple Stream access method instances may open concurrently on one stream file. When opened for "update," simultaneous access to overlapping sub-streams can cause conflicts. To prevent these, locks can be applied at either the full-file or sub-stream level: the initial client reading a sub-stream acquires a lock that is released upon updating; other clients must wait for this lock to be freed before proceeding.

Hierarchical directories

Hierarchical directories consist of files that link names to their corresponding locations; a hierarchical structure emerges when directory entries point to other directories. Utilizing DDM client/server tools, applications have the capability to remotely create, delete, rename directories, and adjust their properties. Directory entries are accessed sequentially through the DDM Directory Access Method. Identified files can be renamed, duplicated, or relocated between directories.

DDM queues

DDM queues facilitate short-term communication between programs by exchanging records. Although these queues exist on a single machine, they allow access from multiple systems. There are three queue varieties established by distinct commands:

First-in-first-out queues (functioning as asynchronous pipes connecting enqueuing and dequeuing processes)
Last-in-first-out queues (operating as pushdown stacks)
Keyed queues (enabling a fan-out mechanism where dequeuing is based on keys)

Queues possess attributes including creation timestamp, maximum record count, and record size (either fixed or variable). Unlike DDM files, queues do not require opening an access method; programs enqueue and dequeue records according to the queue’s specific type.

Programs can remove records, suspend queue operations, and view or alter queue attributes. Locks may be applied either to entire queues or individual records to prevent conflicts; other clients must wait until these locks are released.

Relational databases

A relational database (RDB) utilizes Structured Query Language (SQL) to define, manage, query, update, index, and interrelate tables of data. Users or applications send SQL commands to an RDB and receive tables of data along with status information. SQL statements may also be compiled into packages for optimized execution of complex or frequently used queries, particularly when accessing tables remotely.

The Distributed Relational Database Architecture (DRDA) is integrated within the broader DDM framework as described in Object-Orientation. DDM manager-level components that support DRDA include RDB (relational database) and SQLAM (SQL Application Manager).

Data description and conversion

The DDM design strives for transparency so that existing applications can access remote data management services without needing recompilation. While interface-level transparency addresses file access, achieving field-level transparency requires automatic data conversion between different encoding formats.

For example, IBM mainframes use hexadecimal floating-point representation and EBCDIC, whereas IBM PCs employ IEEE floating-point format and ASCII. Additionally, programming languages differ in how they map record fields into memory. Transparent conversion necessitates comprehensive descriptions of both client and server record formats to align fields by name and perform the required transformations.

Since record definitions are generally language-specific declarations, a universal, language-neutral approach was essential for describing various fixed- and variable-length record layouts across platforms.

This requirement led to the development of the Data Description and Conversion (DD&C) framework utilizing a specialized language called A Data Language (ADL). ADL describes client/server data views and specifies conversion rules. Servers invoke compiled ADL programs to convert records during data transfer.

DD&C also proposed converting programming language declarations to and from ADL to enable cross-language interoperability. Although this capability was never realized due to its complexity and expense, an ADL compiler exists. ADL programs are employed by DFM and the IBM 4680 Store System for conversions—though application developers must manually write these programs.

IBM's DDM-Based Offerings

IBM incorporated various components of the DDM framework into a range of its products:

IBM System/370
- MVS (including MVS/SP and MVS/ESA)
  - Database 2 – functions as both DRDA client and server
  - CICS – served as a record file server within CICS transaction processing; support ended with CICS for z/OS V5.2 and subsequent versions
- VM (operating system) (covering VM/SP and VM/ESA)
  - SQL/DS – provided DRDA client and server capabilities
- DOS/VSE
  - CICS – acted as a record file server; discontinued starting with CICS for z/VSE V2.1 and later
- z/OS
  - Distributed File Management – operated as a record file server
  - Database 2 – supported DRDA client and server roles

System/36
- System Support Program – included record file client and server functionality

System/38 and its successors: AS/400, iSeries, Power Series
- Supported both record file client and server operations
- Enabled directory and stream file client and server services
- Implemented DRDA client and server features

IBM Personal Computer
- PC DOS
  - Netview/PC – provided directory and stream file client and server functions
  - DDM/PC – offered directory and stream file client capabilities
  - PC Support/36 – enabled directory and stream file client access
  - PC Support/400 – facilitated directory and stream file client operations
- Personal System/2 running OS/2
  - PC Support/400 – delivered stream file and directory client/server functionality
  - Included DRDA client and server support

IBM 4680 and IBM 4690 Store Systems
- Delivered record file client and server services
- Provided directory and stream file client and server capabilities

RS/6000 running AIX
- Offered both DRDA client and server support

DDM Solutions from Other Providers

A detailed catalog of products implementing DRDA can be found in the Open Source DRDA Product Identifier Table.