Распределенная архитектура управления данными ( 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, чтобы они могли количественно оценить ценность программного обеспечения, связывающего разнородные компьютеры.
Однако один из специалистов по планированию «Золотых ворот» , Джон Бонди, остался убежденным и убедил руководство создать отдел, выходящий за рамки обычного контроля со стороны Рочестерской лаборатории, чтобы не было немедленной необходимости в заранее определенном экономическом обосновании. Далее он сузил ее задачу, включив в нее только поддержку 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 и файловая система System/36. Файловая система метода доступа к виртуальному хранилищу (VSAM) мэйнфреймов IBM. И все же их фактические возможности и интерфейсы значительно различаются, так какие же возможности и интерфейсы должна поддерживать архитектура DDM? См. файлы, ориентированные на запись.
Первоначальная работа над DDM в рамках проекта Golden Gate следовала примеру международного стандарта доступа и управления передачей файлов ( 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 под управлением IBM PC DOS и IBM RS/6000 под управлением IBM AIX ( версию Unix от IBM). См. Потоковые файлы.
Уровень 2 архитектуры DDM был опубликован в 1988 году. Ян Фишер и Сунил Гайтонде выполнили большую часть работы по архитектуре поддержки DDM для каталогов и потоковых файлов.
В 1986 году IBM выпустила на рынок четыре различных продукта реляционных баз данных (RDB), каждый из которых создан для конкретной операционной системы IBM. Ученые из исследовательской лаборатории IBM в Альмадене разработали System/R*, прототип распределенной RDB, и они почувствовали, что пришло время превратить ее в рыночные продукты. Однако System/R* был основан на System/R, исследовательском прототипе RDB, и его было нелегко добавить к продуктам IBM RDB. См. [6] для обсуждения RDB в среде распределенной обработки.
Роджер Рейнш из Центра программирования IBM в Санта-Терезе возглавил группу специалистов по различным продуктам для определения архитектуры распределенной реляционной базы данных (DRDA). Он записался:
В 1990 году одновременно были опубликованы уровни архитектуры DDM 3 и DRDA [7] . И DDM, и DRDA были определены как стратегические компоненты архитектуры системных приложений (SAA) IBM . DRDA была реализована во всех четырех продуктах IBM RDB и других поставщиков.
Награды были вручены ключевым участникам разработки DRDA. Ричард Сандерс получил награду за выдающийся вклад , а Роджер Рейнш и Ричард Демерс получили награду за выдающиеся инновации .
Проект Distributed File Management (DFM) [8] был инициирован с целью добавления служб DDM в операционную систему IBM MVS, чтобы позволить программам на удаленных компьютерах создавать файлы VSAM , управлять ими и получать к ним доступ . Джон Хафферд, менеджер проекта DFM, обратился к команде DDM Architecture за средством преобразования полей данных в записях при их передаче между системами. Ричард Демерс взял на себя инициативу по этому вопросу при поддержке Коичи Ямагучи из проекта DFM. См. Описание и преобразование данных.
Следующие дополнительные услуги были определены Ричардом Сандерсом, Яном Фишером и Сунилом Гаитонде в архитектуре DDM на уровне 4:
Уровень 4 архитектуры DDM был опубликован в 1992 году.
Работа над архитектурой DDM уровня 5 заключалась в поддержке
Ян Фишер был архитектором, ответственным за DDM уровня 5, который был опубликован Open Group, а не IBM. Вскоре после этого группа IBM по архитектуре DDM была расформирована.
Архитектура DDM представляет собой формально определенный и хорошо структурированный набор спецификаций. В этом разделе представлены ключевые технические концепции, лежащие в основе DDM. [2]
Архитектура DDM определяет протокол клиент/сервер; то есть клиент запрашивает услуги у сервера, который взаимодействует со своими локальными ресурсами для выполнения запрошенной услуги, результаты которой, данные и индикаторы состояния, возвращаются клиенту. На приведенной выше диаграмме показаны роли клиентов и серверов DDM по отношению к локальным ресурсам. (Здесь используется общая терминология клиентов и серверов , но в архитектуре DDM клиент называется исходным сервером , а сервер называется целевым сервером .)
Архитектура DDM является объектно-ориентированной . Все сущности, определенные DDM, являются объектами, определяемыми самоопределяющимися объектами классов . Сообщения, ответы и данные, которые передаются между системами, представляют собой сериализованные объекты. Каждый объект определяет свою длину, идентифицирует свой класс с помощью кода DDM и содержит данные, определенные его классом. Кроме того, его класс определяет команды, которые могут быть отправлены его экземплярам, когда объект находится на клиенте или сервере DDM, тем самым инкапсулируя объект с помощью ограниченного набора операций.
Структурно архитектура DDM состоит из иерархических уровней объектов, каждый из которых проявляет возникающие свойства на все более высоких уровнях.
Хотя архитектура DDM является объектно-ориентированной, продукты DDM были реализованы с использованием языков и методов, типичных для их хост-систем. Версия DDM для Smalltalk была разработана для IBM PC компанией Object Technology International , при этом соответствующие классы Smalltalk автоматически создавались из Справочного руководства DDM.
DDM — это открытая архитектура. Продукты DDM могут реализовывать подмножества архитектуры DDM; они также могут создавать свои собственные расширения.[11]
Команда DDM «Обмен атрибутами сервера» — это первая команда, отправляемая при подключении клиента к серверу. Он идентифицирует клиента и указывает менеджеров, которые требуются клиенту, а также уровень архитектуры 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 от клиента, например, с записями, которые должны быть загружены в файл с помощью команды «Загрузить файл» . Идентификатор запроса также связывает RQSDSS от клиента с RPYDSS или OBJDSS от сервера к клиенту.
Справочное руководство DDM [12] [13] состоит из именованных объектов «Меню», «Справка» и «Класс». Подклассы класса DDM Class описываются переменными, которые определяют
Эти объекты могут содержать ссылки на другие именованные объекты в тексте и спецификациях, тем самым создавая гипертекстовые связи между страницами Справочного руководства DDM. Страницы меню и справки образуют интегрированное руководство по DDM. Бумажная версия Справочного руководства DDM уровня 3 громоздка, содержит более 1400 страниц и несколько неудобна в использовании, но интерактивная версия также была создана с использованием внутренних средств связи IBM. Учитывая относительно низкую скорость этих средств связи, они в основном использовались в лаборатории IBM в Рочестере.
В дополнение к Справочному руководству 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 .
Метод доступа к потоку — это случай использования файла потока одним клиентом. Курсор отслеживает позицию текущего байта подпотока, используемого клиентом. Используя различные команды 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 Data Language (ADL) [15] для описания клиентских и серверных представлений записей данных и для указание конверсий. Скомпилированные программы ADL затем могут быть вызваны сервером для выполнения необходимых преобразований по мере того, как записи передаются на сервер или с него.
Архитектура DD&C пошла дальше и определила средства, с помощью которых операторы объявления языка программирования могут автоматически преобразовываться в ADL и обратно, и, следовательно, из одного языка программирования в другой. Эта возможность так и не была реализована из-за ее сложности и стоимости. Однако был создан компилятор ADL, и программы ADL, если они доступны, вызываются для выполнения преобразований с помощью DFM и системы IBM 4680 Store. [16] Однако прикладным программистам необходимо вручную писать программы ADL.
Следующие продукты IBM реализовали различные подмножества архитектуры DDM:
Полный список продуктов, в которых реализован DRDA, см. в таблице идентификаторов продуктов DRDA с открытым исходным кодом.
{{cite journal}}: CS1 maint: несколько имен: список авторов ( ссылка )CICS DDM больше не доступен от IBM, и поддержка была прекращена с 31 декабря 2003 г. CICS DDM больше не доступен в CICS TS, начиная с версии 5.2.
Поддержка управления распределенными данными CICS (DDM) стабилизирована в CICS TS для VSE/ESA V1.1.1.
В будущем выпуске CICS TS для z/VSE IBM намерена прекратить поддержку CICS DDM.
Управление распределенными данными CICS (CICS/DDM) не поддерживается CICS TS for z/VSE V2.1.