Распределенная архитектура управления данными ( DDM ) — это открытая, опубликованная программная архитектура IBM для создания, управления и доступа к данным на удаленном компьютере. DDM изначально была разработана для поддержки файлов, ориентированных на записи; она была расширена для поддержки иерархических каталогов, потоковых файлов, очередей и обработки системных команд; она была дополнительно расширена, чтобы стать основой архитектуры распределенной реляционной базы данных IBM (DRDA); и, наконец, она была расширена для поддержки описания и преобразования данных. Определенная в период с 1980 по 1993 год, DDM определяет необходимые компоненты, сообщения и протоколы, все основанные на принципах объектной ориентации. DDM сама по себе не является частью программного обеспечения; реализация DDM принимает форму клиентских и серверных продуктов. Как открытая архитектура , продукты могут реализовывать подмножества архитектуры DDM, а продукты могут расширять DDM для удовлетворения дополнительных требований. Взятые вместе, продукты DDM реализуют распределенную файловую систему .
Разработчики распределенных приложений должны определить наилучшее размещение программ и данных приложения с точки зрения количества и частоты передаваемых данных, а также с учетом управления данными, безопасности и своевременности. Существует три модели клиент-сервер для проектирования распределенных приложений:
Архитектура DDM изначально была разработана для поддержки модели «толстого клиента» распределенных приложений; она также поддерживает передачу целых файлов.
Архитектура DDM предоставляет распределенным приложениям следующие преимущества: [1]
Архитектура DDM представляет собой набор спецификаций для сообщений и протоколов, которые позволяют управлять данными, распределенными по сети компьютеров, и получать к ним доступ. [2]
Архитектура системных сетей IBM (SNA) изначально была разработана для обеспечения иерархического соединения рабочих станций с мэйнфреймами IBM. Коммуникационные сети, доступные в то время, были жестко спроектированы в терминах фиксированных соединений между мэйнфреймом и его набором рабочих станций, которые находились под полным программным управлением мэйнфрейма. Другие коммуникации между мэйнфреймами также были в терминах фиксированных соединений, используемых программным обеспечением, определенным для конкретных целей. Поскольку коммуникационные сети становились все более гибкими и динамичными, желательными стали общие одноранговые коммуникации, в которых программа на одном компьютере могла инициировать и взаимодействовать с программой на другом компьютере.
Когда в начале 1980-х годов была определена архитектура IBM SNA Advanced Program to Program Communications (APPC), также стало очевидно, что APPC можно использовать для предоставления услуг операционной системы на удаленных компьютерах. Рабочая группа SNA продолжила эту идею и наметила несколько возможных распределенных служб, таких как файловые службы, службы принтеров и службы системной консоли, но не смогла инициировать разработку продукта. Программное обеспечение APPC еще не было доступно на мэйнфреймах, и, что более важно, мэйнфреймы все еще рассматривались в первую очередь как автономные системы. В результате работа над распределенными службами была приостановлена рабочей группой SNA.
Члены рабочей группы SNA из лаборатории разработки IBM в Рочестере, штат Миннесота, были убеждены, что существует экономическое обоснование для распределенных служб среди компьютерных систем среднего уровня, производимых в Рочестере. Была реализована примитивная форма распределенных файловых служб, называемая Distributed Data File Facility (DDFF), для соединения мини-компьютеров IBM System/3 , IBM System/34 и IBM System/36 . Кроме того, компьютеры IBM System/36 и IBM System/38 продавались клиентам в нескольких экземплярах, и была очевидная необходимость в том, чтобы, например, компьютеры штаб-квартиры компании могли взаимодействовать с компьютерами на ее различных складах. APPC был реализован на этих системах и использовался различными приложениями клиентов. Идея распределенных служб операционной системы затем была возрождена в виде проекта Golden Gate , и была предпринята попытка оправдать его разработку. Эта попытка также потерпела неудачу; вся идея распределенных служб была слишком новой для планировщиков продуктов IBM, чтобы иметь возможность количественно оценить ценность программного обеспечения, которое связывало бы разнородные компьютеры.
Однако один из планировщиков Golden Gate , Джон Бонди, остался убежденным и убедил руководство создать отдел вне обычного контроля лаборатории Рочестера, чтобы не было немедленной необходимости в предопределенном бизнес-кейсе. Кроме того, он сузил его миссию, включив только поддержку Distributed Data Management (DDM), в частности, поддержку файлов, ориентированных на записи . Затем он убедил опытного архитектора программного обеспечения Ричарда А. Демерса присоединиться к нему в задачах определения архитектуры DDM и продажи идеи DDM системным домам IBM.
Первый год этих усилий был в значительной степени бесплодным, поскольку системные дома IBM продолжали требовать авансом бизнес-кейсы и настаивали на форматах сообщений, изоморфных интерфейсам блоков управления их локальных файловых систем. Кроме того, поскольку персональные компьютеры начали использоваться в качестве терминалов, подключенных к мэйнфреймам, утверждалось, что простое улучшение потока данных 3270 позволит ПК получать доступ к данным мэйнфреймов.
В этот период Демерс разработал архитектурную модель клиентов и серверов DDM, их компонентов и взаимодействий между взаимодействующими компьютерами. Кроме того, он определил общий формат сообщений DDM на основе принципов объектной ориентации, впервые предложенных языком программирования Smalltalk и IBM System/38. Эта модель прояснила, как продукты DDM могут быть реализованы на различных системах. См. Как работает DDM.
В 1982 году планировщики System/36 убедились, что рынок для ориентированных на записи файлов DDM услуг достаточен. [3]
Общий формат сообщений DDM уже был разработан, но какие конкретные сообщения должны быть определены? Файловая система System/36 была определена для удовлетворения потребностей языков программирования третьего поколения (3GL), ориентированных на записи, таких как Fortran , COBOL , PL/I и IBM RPG , как и файловая система System/38 и файловая система Virtual Storage Access Method (VSAM) мэйнфреймов IBM. И все же их фактические возможности и интерфейсы значительно различались, так какие возможности и интерфейсы должна поддерживать архитектура DDM? См. файлы, ориентированные на записи.
Первоначальная работа над DDM в рамках проекта Golden Gate следовала примеру международного стандарта File Transfer Access and Management ( FTAM ) для распределенных файлов, но он был очень абстрактным и его было трудно сопоставить с локальными файловыми службами. Фактически, это было одним из препятствий для принятия системными домами IBM. Кеннет Лоуренс, системный архитектор, ответственный за файловые службы System/36, утверждал, что было бы лучше определить сообщения, которые, по крайней мере, одна система IBM могла бы легко реализовать, а затем позволить другим системам запрашивать любые необходимые им изменения. Естественно, он выступал за поддержку требований System/36. После года неудачных попыток продать идею DDM другим системным домам IBM, аргументы Лоуренса возобладали.
Ричард Сандерс присоединился к команде по архитектуре DDM и работал с Лоуренсом и Демерсом над определением конкретных сообщений, необходимых для System/36 DDM. Прогресс в определении DDM побудил System/38 также принять участие. Это расширило область поддержки файлов записей DDM для удовлетворения многих требований расширенной файловой системы System/38.
Файлы существуют в контексте, предоставляемом операционной системой, которая предоставляет услуги по организации файлов, для их совместного использования с одновременными пользователями и для их защиты от несанкционированного доступа. На уровне 1 DDM доступ к удаленным файловым каталогам не поддерживался за пределами передачи полностью определенного имени файла, который будет использоваться. Однако требовались безопасность и совместное использование. Сандерс выполнил проектную работу в этих областях. Сандерс также определил специальные протоколы, касающиеся использования средств связи, которые были включены в компонент, называемый DDM Conversational Communications Manager. Первоначально реализованный с использованием APPC, он позже был реализован с использованием TCP/IP .
После завершения работы над продуктом System/36 DDM Лоуренс работал с программистами из лаборатории IBM в Херсли-Парке (Великобритания), чтобы адаптировать большую часть программирования сервера System/36 DDM для использования в среде обработки транзакций IBM Customer Information Control System (CICS), тем самым сделав CICS сервером DDM для операционных систем мэйнфреймов MVS и VSE. [4] Лоуренс также работал с программистами из лаборатории IBM в Кэри (Северная Каролина), чтобы реализовать ориентированный на записи клиент DDM для IBM PC DOS .
Уровень 1 архитектуры DDM был официально опубликован в 1986 году. Во время этого объявления IBM вручила премию «За выдающиеся технические достижения» Кеннету Лоуренсу, премию «За выдающийся вклад» Ричарду Сандерсу и премию «За выдающиеся инновации» Ричарду Демерсу.
С ростом значимости IBM PC и операционной системы Unix в сетевых средах поддержка DDM также потребовалась для иерархических каталогов и потоковых файлов IBM Personal Computer под управлением IBM PC DOS и IBM RS/6000 под управлением IBM AIX (версия Unix от IBM). См. Потоковые файлы.
Архитектура DDM уровня 2 была опубликована в 1988 году. Ян Фишер и Сунил Гаитонде проделали большую часть работы по архитектуре поддержки DDM для каталогов и потоковых файлов.
В 1986 году IBM выпустила на рынок четыре различных продукта реляционных баз данных (RDB), каждый из которых был создан для определенной операционной системы IBM. Ученые исследовательской лаборатории IBM Almaden разработали System/R*, прототип распределенной RDB, и они посчитали, что пришло время превратить его в рыночные продукты. Однако System/R* была основана на System/R, исследовательском прототипе RDB, и ее было нелегко добавить к продуктам IBM RDB. См. [6] для обсуждения RDB в среде распределенной обработки.
Роджер Райнш из IBM Santa Theresa Programming Center возглавил кросс-продуктовую команду по определению архитектуры распределенной реляционной базы данных (DRDA). Он привлек:
В 1990 году DDM Architecture Level 3 и DRDA [7] были опубликованы одновременно. И DDM, и DRDA были обозначены как стратегические компоненты IBM Systems Application Architecture (SAA). DRDA была реализована всеми четырьмя продуктами IBM RDB и другими поставщиками.
Награды были вручены ключевым участникам разработки DRDA. Ричард Сандерс получил премию за выдающийся вклад , а Роджер Райнш и Ричард Демерс получили премии за выдающиеся инновации .
Проект Distributed File Management (DFM) [8] был инициирован для добавления служб DDM в операционную систему MVS IBM, чтобы программы на удаленных компьютерах могли создавать, управлять и получать доступ к файлам VSAM . Джон Хафферд, менеджер проекта DFM, обратился к команде DDM Architecture за средством преобразования полей данных в записях при их передаче между системами. Ричард Демерс взял на себя руководство этой проблемой, которому помогал Коити Ямагучи из проекта DFM. См. Описание и преобразование данных.
Следующие дополнительные сервисы были определены Ричардом Сандерсом, Яном Фишером и Сунилом Гаитонде в архитектуре DDM на уровне 4:
Архитектура DDM уровня 4 была опубликована в 1992 году.
Архитектурная работа на уровне DDM 5 состояла из поддержки
Ян Фишер был архитектором, ответственным за DDM уровня 5, который был опубликован Open Group, а не IBM. Вскоре после этого группа архитектуры IBM DDM была расформирована.
Архитектура DDM — это формально определенный и высокоструктурированный набор спецификаций. В этом разделе представлены ключевые технические концепции, лежащие в основе DDM. [2]
Архитектура DDM определяет протокол клиент/сервер; то есть клиент запрашивает услуги у сервера, который взаимодействует со своими локальными ресурсами для выполнения запрошенной услуги, результаты которой, данные и индикаторы состояния, возвращаются клиенту. Приведенная выше диаграмма иллюстрирует роли клиентов и серверов DDM по отношению к локальным ресурсам. (Здесь используется общая терминология клиентов и серверов , но в архитектуре DDM клиент называется исходным сервером , а сервер называется целевым сервером .)
Архитектура DDM является объектно-ориентированной . Все сущности, определенные DDM, являются объектами, определенными самоопределяющимися объектами Class . Сообщения, ответы и данные, которые передаются между системами, являются сериализованными объектами. Каждый объект указывает свою длину, идентифицирует свой класс с помощью кодовой точки DDM и содержит данные, определенные его классом. Кроме того, его класс определяет команды, которые могут быть отправлены его экземплярам, когда объект находится в клиенте или сервере DDM, тем самым инкапсулируя объект ограниченным набором операций.
Структурно архитектура DDM состоит из иерархических уровней объектов, каждый из которых проявляет возникающие свойства на все более высоких уровнях.
Хотя архитектура DDM является объектно-ориентированной, продукты DDM были реализованы с использованием языков и методов, типичных для их хост-систем. Версия Smalltalk DDM была разработана для IBM PC компанией Object Technology International , с соответствующими классами Smalltalk, автоматически созданными из справочного руководства DDM.
DDM — это открытая архитектура. Продукты DDM могут реализовывать подмножества архитектуры DDM; они также могут создавать свои собственные расширения. [11]
Команда DDM 'Exchange Server Attributes' является первой командой, отправляемой при подключении клиента к серверу. Она идентифицирует клиента и указывает менеджеров, которые требуются клиенту, а также уровень архитектуры DDM, на котором требуется поддержка. Сервер отвечает, идентифицируя себя и указывая, на каком уровне он поддерживает запрошенных менеджеров. Общее правило заключается в том, что продукт, поддерживающий уровень X менеджера DDM, должен также поддерживать уровень X-1, чтобы новые серверные продукты могли подключаться к старым клиентским продуктам.
Подмножества DDM могут быть реализованы для удовлетворения различных требований к продукту:
Когда клиент DDM подключен к известному серверу DDM, например, клиент System/38 к серверу System/38, архитектуру DDM также можно расширить, добавив
Такие расширения могут быть определены в объектно-ориентированной среде DDM, что позволит использовать существующие средства обработки сообщений DDM.
В чисто объектно-ориентированной реализации DDM клиенты и серверы и все содержащиеся в них менеджеры и объекты существуют в куче памяти, с указателями (адресами памяти), используемыми для их соединения. Например, объект команды указывает на каждый из своих объектов параметров. Но команда не может быть передана от клиента к серверу таким образом; изоморфная копия команды должна быть создана как одна непрерывная строка битов. В куче команда состоит из размера команды в куче, указателя на класс команды и указателей на каждый из объектов параметров команды. Линеаризованная команда состоит из общей длины линеаризованной команды, кодовой точки, идентифицирующей класс команды, и каждого из ее линеаризованных объектов параметров. Архитектура DDM назначает уникальные кодовые точки каждому классу объектов. Этот простой метод используется для всех объектов, передаваемых между клиентом и сервером, включая команды, записи и ответные сообщения.
Все эти линеаризованные объекты помещаются в конверты, которые позволяют агентам клиента и сервера координировать их обработку. В архитектуре DDM эти конверты называются структурами потоков данных (DSS). Команды помещаются в запрос DSS (RQSDSS), ответы помещаются в ответ DSS (RPYDSS), а другие объекты помещаются в объект DSS (OBJDSS). В RQSDSS может быть только одна команда и только один ответ в RPYDSS, но в OBJDSS может быть помещено много объектов, таких как записи. Кроме того, много OBJDSS могут быть связаны с RQSDSS или PRYDSS для размещения необходимого количества объектов. DSS состоит из общей длины DSS, байта флага, идентифицирующего тип DSS, идентификатора запроса и линеаризованных объектов в DSS. Идентификатор запроса связывает RQSDSS с последующими OBJDSS от клиента, такими как записи, которые должны быть загружены в файл командой Load File . Идентификатор запроса также связывает RQSDSS от клиента с RPYDSS или OBJDSS от сервера к клиенту.
Справочное руководство DDM [12] [13] состоит из именованных объектов Menu, Help и Class. Подклассы класса DDM Class описываются переменными, которые указывают
Эти объекты могут содержать ссылки на другие именованные объекты в тексте и спецификациях, тем самым создавая гипертекстовые связи между страницами Справочного руководства DDM. Меню и страницы справки образуют интегрированное руководство по DDM. Бумажная версия Справочного руководства DDM уровня 3 громоздка, содержит более 1400 страниц, и несколько неудобна в использовании, но интерактивная версия также была создана с использованием внутренних средств связи IBM. Учитывая относительно низкую скорость этих средств связи, она в основном использовалась в лаборатории IBM Rochester.
В дополнение к Справочному руководству по DDM, документ «Общая информация » [1] содержит информацию о DDM на уровне руководства, а «Руководство программиста» [11] суммирует концепции DDM для программистов, реализующих клиенты и серверы.
Архитектура DDM определяет три общие модели файлов: файлы, ориентированные на записи, файлы, ориентированные на потоки, и иерархические каталоги.
Архитектура DDM предоставляет следующие услуги для управления удаленными файлами:
Файлы, ориентированные на записи, были разработаны для удовлетворения требований к вводу, выводу и хранению данных языков программирования третьего поколения (3GL), таких как Fortran, Cobol, PL/I и RPG. Вместо того, чтобы каждый язык предоставлял собственную поддержку для этих возможностей, они были включены в службы, предоставляемые операционными системами.
Запись — это ряд связанных полей данных, таких как имя, адрес, идентификационный номер и зарплата одного сотрудника, в котором каждое поле кодируется и сопоставляется с непрерывной строкой байтов. Ранние компьютеры имели ограниченные возможности ввода и вывода, как правило, в виде стопок 80-колоночных перфокарт или в виде бумажных или магнитных лент. Записи приложений, такие как записи данных сотрудников, последовательно считывались или записывались по одной записи за раз и обрабатывались пакетами. Когда стали доступны устройства хранения с прямым доступом, языки программирования добавили для программ способы случайного доступа к записям по одной за раз, такие как доступ по значениям ключевых полей или по положению записи в файле. Все записи в файле могут иметь одинаковый формат (как в файле заработной платы) или разные форматы (как в журнале событий). Некоторые файлы доступны только для чтения, поскольку их записи, после записи в файл, могут быть только прочитаны, в то время как другие файлы позволяют обновлять свои записи.
Модели файлов DDM, ориентированные на записи, состоят из атрибутов файла, таких как дата его создания, дата последнего обновления, размер его записей и слоты, в которых могут храниться записи. Записи могут быть как фиксированной, так и переменной длины, в зависимости от носителя, используемого для хранения записей файла. DDM определяет четыре типа файлов, ориентированных на записи:
Архитектура DDM также определяет множество методов доступа для работы с файлами, ориентированными на записи, различными способами. Метод доступа — это экземпляр использования файла, созданный с помощью команды OPEN, который подключается к файлу после определения того, имеет ли клиент право его использовать. Метод доступа отключается от файла с помощью команды CLOSE.
Метод доступа отслеживает запись, обрабатываемую в данный момент, с помощью курсора. Используя различные команды SET, курсор можно заставить указывать на начало или конец файла, на следующую или предыдущую последовательную запись файла, на запись с определенным значением ключа или на следующую или предыдущую запись в порядке их ключей.
Несколько экземпляров методов доступа могут быть открыты для файла одновременно, каждый из которых обслуживает одного клиента. Если файл открыт для доступа для обновления, могут возникнуть конфликты, когда к одной и той же записи обращаются несколько клиентов. Чтобы предотвратить такие конфликты, можно получить блокировку для всего файла. Кроме того, если файл открыт для обновления , блокировка для записи устанавливается первым клиентом, который ее прочитал, и снимается, когда этот клиент ее обновит. Все остальные клиенты должны ждать снятия блокировки.
Потоковые файлы состоят из одной последовательности байтов, на которой программы могут отображать данные приложений так, как им хочется. Потоковые файлы являются основной файловой моделью, поддерживаемой Unix и Unix-подобными операционными системами, а также Windows . DDM определяет однопотоковую файловую модель и однопотоковый метод доступа.
Модель потока DDM состоит из атрибутов файла, таких как дата его создания и размер потока, а также непрерывного потока байтов. Доступ к потоку можно получить с помощью метода доступа к потоку. Прикладные программы записывают данные в части потока, даже если эти данные состоят из записей. Они отслеживают местоположение элементов данных в потоке любым желаемым ими способом. Например, поток данных файлов документов определяется программой обработки текста, такой как Microsoft Word , а поток данных файла электронной таблицы — программой, такой как Microsoft Excel .
Метод доступа Stream — это пример использования потокового файла одним клиентом. Курсор отслеживает позицию текущего байта подпотока, используемого клиентом. Используя различные команды SET, курсор можно заставить указывать на начало или конец файла, на любую определенную позицию в файле или на любое положительное или отрицательное смещение от текущей позиции.
Несколько экземпляров метода доступа Stream могут быть открыты для файла одновременно, каждый из которых обслуживает одного клиента. Если файл открыт для доступа «обновления», могут возникнуть конфликты, когда к одному и тому же подпотоку обращаются несколько клиентов. Чтобы предотвратить такие конфликты, можно получить блокировку для всего файла. Кроме того, если файл открыт для обновления, блокировка на подпоток устанавливается первым клиентом, который «прочитал» его, и снимается, когда этот клиент «обновит» его. Все остальные клиенты должны ждать снятия блокировки.
Иерархические каталоги — это файлы, записи которых связывают имя с местоположением. Иерархия возникает, когда запись каталога идентифицирует имя и местоположение другого каталога. Используя клиентские и серверные продукты DDM, программа может создавать, удалять и переименовывать каталоги на удаленном компьютере. Они также могут перечислять и изменять атрибуты файлов удаленных каталогов. Записи в каталоге можно последовательно читать с помощью метода доступа к каталогу DDM. Файлы, идентифицированные записями каталога, можно переименовывать, копировать и перемещать в другой каталог.
Очереди — это механизм связи, который обеспечивает краткосрочную связь между программами посредством записей. Очередь DDM находится в одной системе, но к ней могут обращаться программы из нескольких систем. Существует три подкласса очередей DDM, которые можно создать в целевой системе с помощью отдельных команд создания:
Модель очереди DDM состоит из атрибутов очереди, таких как дата ее создания, количество записей, которые может содержать очередь, и длина записей. Записи в очереди могут быть как фиксированной, так и переменной длины.
В отличие от моделей файлов DDM, нет необходимости открывать метод доступа в очереди. Программы могут добавлять записи в очередь и получать записи из очереди, как определено классом очереди. Программы также могут очищать записи из очереди, останавливать операции в очереди, перечислять атрибуты очереди и изменять атрибуты очереди. Программы также могут блокировать очередь или отдельные записи в очереди, чтобы предотвратить конкуренцию со стороны других программ. Все остальные клиенты должны ждать снятия блокировки.
Реляционная база данных ( RDB) — это реализация языка структурированных запросов (SQL), которая поддерживает создание, управление, запросы, обновление, индексацию и взаимосвязи таблиц данных. Интерактивный пользователь или программа могут выдавать SQL-заявления в RDB и получать в ответ таблицы данных и индикаторы состояния. Однако SQL-заявления также могут компилироваться и сохраняться в RDB в виде пакетов, а затем вызываться по имени пакета. Это важно для эффективной работы прикладных программ, которые выдают сложные, высокочастотные запросы. Это особенно важно, когда таблицы, к которым требуется доступ, находятся в удаленных системах.
Распределенная реляционная архитектура базы данных (DRDA) прекрасно вписывается в общую структуру DDM, как обсуждалось в разделе «Объектно-ориентированное программирование». (Однако DDM также можно рассматривать как компонентную архитектуру DRDA, поскольку требуются и другие спецификации [2] ). Объекты уровня менеджера DDM, поддерживающие DRDA, называются RDB (реляционная база данных) и SQLAM (диспетчер приложений SQL).
Прозрачность является ключевой целью архитектуры DDM. Без перекомпиляции должно быть возможно перенаправлять существующие прикладные программы на службы управления данными удаленного компьютера. Для файлов это в значительной степени было достигнуто клиентами DDM на уровне интерфейса/функций, но как насчет полей данных в записи? Полная прозрачность требует, чтобы клиентские прикладные программы могли записывать и читать поля, закодированные их локальной системой управления данными, независимо от того, как их кодирует любой удаленный сервер, а это подразумевает автоматическое преобразование данных .
Например, мэйнфреймы IBM кодируют числа с плавающей точкой в шестнадцатеричном формате, а символьные данные — в EBCDIC , тогда как персональные компьютеры IBM кодируют их в формате IEEE и ASCII . Дальнейшая сложность возникла из-за способов, которыми различные компиляторы языков программирования сопоставляют поля записи со строками битов, байтов и слов в памяти. Прозрачное преобразование записи требует подробных описаний как клиентского представления, так и серверного представления записи. Учитывая эти описания, поля клиентского и серверного представлений могут быть сопоставлены по имени поля, и могут быть выполнены соответствующие преобразования.
Ключевой проблемой является получение достаточно подробных описаний записей, но описания записей обычно указываются абстрактно в прикладных программах посредством операторов объявления, определенных языком программирования, с языковым компилятором, обрабатывающим детали кодирования и отображения. В распределенной среде обработки необходим единый стандартизированный способ описания записей, который не зависит от всех языков программирования, способ, который может описывать широкий спектр форматов записей фиксированной и переменной длины, найденных в существующих файлах.
Результатом стало определение всеобъемлющей архитектуры описания и преобразования данных (DD&C), [14] основанной на новом специализированном языке программирования, языке данных A (ADL), [15] для описания клиентских и серверных представлений записей данных и для указания преобразований. Скомпилированные программы ADL затем могут вызываться сервером для выполнения необходимых преобразований по мере того, как записи передаются на сервер или с него.
Архитектура DD&C пошла дальше и определила средство, с помощью которого операторы декларирования языка программирования могут автоматически преобразовываться в ADL и из него, и, таким образом, из одного языка программирования в другой. Эта возможность так и не была реализована из-за ее сложности и стоимости. Однако был создан компилятор ADL, и программы ADL вызываются, когда они доступны, для выполнения преобразований DFM и IBM 4680 Store System. [16] Однако программистам приложений необходимо вручную писать программы ADL.
Следующие продукты IBM реализовали различные подмножества архитектуры DDM:
Полный список продуктов, в которых реализована технология DRDA, см. в таблице идентификаторов продуктов DRDA с открытым исходным кодом.
{{cite journal}}: CS1 maint: несколько имен: список авторов ( ссылка )CICS DDM больше не доступен от IBM, и поддержка была прекращена с 31 декабря 2003 года. CICS DDM больше не доступен в CICS TS, начиная с версии 5.2.
CICS Distributed Data Management (DDM) стабилизирована в CICS TS для VSE/ESA V1.1.1. В будущем выпуске CICS TS для z/VSE IBM намерена прекратить поддержку CICS DDM.
CICS Distributed Data Management (CICS/DDM) не поддерживается в CICS TS для z/VSE V2.1.