Читать онлайн «Основы AS/400». Страница 82

Как уже говорилось, сегодня в устройствах ввода-вывода AS/400 все еще преобладает шина SPD. Поэтому рассказ о вводе-выводе в следующих разделах я буду иллюстрировать примерами именно для этой шины, при необходимости, отмечая существенные отличия с вводом-выводом по шине PCI. Впрочем, везде, за исключением самих нижних уровней SLIC, эти различия незначительны. Архитектура ввода-вывода AS/400 предназначена для работы с самыми разными интерфейсами, так что добавление в будущем новых интерфейсов окажет минимальное влияние на существующее системное ПО. И конечно, с точки зрения приложений никаких различий вообще нет; это гарантируется архитектурой, не зависящей от технологии.

Структура ввода-вывода SPD для AS/400, от MI до средства связи между процессами (IPCF) в SLIC, представлена на рисунке 10-2. В верхней части рисунка показан процесс MI — пример пользовательской прикладной программы, выполняющейся в системе.

Рисунок 10.2. Структура ввода-вывода AS/400

В главе 8 для пояснения к рассказу об одноуровневой памяти мы использовали похожий простой пример. Теперь расширим этот пример для иллюстрации операций ввода-вывода. Если Вы помните, тогда прикладная программа выполняла последовательное чтение индексированного файла базы данных, которое, могло быть выполнено либо с помощью команды «Read» ЯВУ, либо с помощью команды: SQL «FETCH». Результатом в обоих случаях — запрос на выполнение операции ввода-вывода для считывания записи с диска. Чтобы сделать пример более интересным, предположим, что вместо считывания записи с диска, подключенного к локальной машине, нужно считать запись из удаленной системы на другом конце линии связи, используя для этого команду SQL.

В главе 6 мы говорили, что интерфейс SQL использует для доступа к удаленным данным DRDA (Distributed Relational Database Architecture). Прежде чем выполнить запрос SQL, нашей программе следует выполнить оператор SQL CONNECT, чтобы задать имя удаленной базы данных в каталоге реляционной базы. После установления связи между двумя системами на удаленную систему может быть послан запрос SQL. Менеджер базы данных удаленной системы выполняет этот запрос и возвращает полученные в результате записи запросившей их системе.

Мы также говорили, что для доступа к удаленной базе данных можно использовать архитектуру DDM (Distributed Data Management). В этом случае обработка файла выполняется на локальной системе. DDM возвращает локальной системе все записи файла, тогда как DRDA — только записи, соответствующие критерию выборки. Выбор для нашего примера интерфейса SQL предполагает использование DRDA. Обработка выполняется на удаленной системе, и мы увидим только ее результаты. Выполнение команды SQL «FETCH» требует четырех операций ввода-вывода: двух — на локальной машине (для отправки запроса SQL и для получения ответа) и двух соответствующих им — на удаленной.

Механизм коммуникаций в AS/400 разбит на слои между OS/400, SLIC и аппаратурой. В нашем примере четыре слоя обработки, а именно:

прикладная поддержка;

менеджер функций;

менеджер ввода-вывода (IOM) станции;

IOM линии.

Аппаратный уровень будет рассмотрен в следующем разделе.

В OS/400 может работать прикладная поддержка коммуникаций, предоставляемая как пользователем, так и IBM. Пользовательская поддержка коммуникаций подключается с помощью API, хотя, конечно, такой поддержкой обладает далеко не каждая прикладная программа. В нашем примере, прикладная поддержка предоставляется компонентом DRDA базы данных AS/400.

Менеджер функций (FM) — это компонент OS/400, предоставляющий интерфейс между приложениями и MI. Для каждого «транспорта» коммуникаций в SLIC обычно имеется соответствующий FM в OS/400. FM отвечает за верхние уровни протокола коммуникаций, например за то, чтобы данные были представлены приложению в той форме, в которой оно этого ожидает.

В нашем примере используется FM для механизма коммуникаций, называемого APPC (advanced program-to-program communications). Впервые АРРС был реализован в System/38, где поддерживал параллельные сессии между системами, позволяя таким образом взаимодействовать нескольким приложениям на разных системах. При этом применялся коммуникационный протокол LU 6.2 (logical unit type 6.2). Порт для посылки и приема данных от приложения на другой системе предоставляло прикладной программе логическое устройство (logical unit).

В AS/400 этот механизм был расширен до уровня APPN (advanced peer-to-peer networking), чтобы удовлетворить потребности распределенной обработки, как в ЛВС, так и в глобальных сетях. APPN, в частности, определяет по распределенному сетевому каталогу местонахождение любой удаленной системы, запрошенной локальным приложением. При наличии нескольких маршрутов между локальной и удаленной системами, APPN на основании выбранного пользователем класса обслуживания вычисляет наилучший. В последних нескольких версиях AS/400 в APPN были добавлены дополнительные функции, включая автоматическое конфигурирование при получении входящего запроса на соединение от неизвестной системы, непосредственно подключенной к ЛВС. Другое новое расширение APPN — поддержка работы по разным сетям, что позволяет приложениям, написанным для API APPC/LU 6.2 без модификации взаимодействовать с удаленным приложением, даже если сетевые сервисы предоставляются несколькими системами.

В нашем примере оператор SQL CONNECT задает устройства, которое должно использоваться в данном запросе ввода-вывода. Предположим, что это устройство — не сетевой адаптер, а модем. Поддержка DRDA в базе данных передает управление FM APPC. Задача FM — построение необходимых структур ввода-вывода и создание соответствующего запроса. FM выдает MI привилегированную команду запроса ввода-вывода («REQIO»), которая не может выполняться прикладной программой. С командой «REQIO» связан SSR (Source Sink Request), который содержит три указателя на:

очередь ответов MI (MIRQ), в которую будет помещено сообщение по завершении ввода-вывода;

описание устройства LUD;

данные приема-передачи (SSD), то есть пользовательский буфер для хранения данных, пересылаемых на устройство или наоборот (в нашем примере — запрос SQL, посылаемый на удаленную систему).

Затем запрос ввода-вывода посылается в виде сообщения в очередь, находящуюся ниже MI и принадлежащую IOM станции. IOM станции — это программа SLIC, которая принимает запросы от FM для установления соединений (иногда называемых сессиями) с удаленными системами, устройствами или приложениями. IOM станции отвечает за обработку средних уровней протокола коммуникаций. В состав функций среднего уровня входит, среди прочих, управление путями коммуникаций — каждому из них соответствует определенный IOM станции: например, поддерживающий коммуникации «точка-точка», или коммуникации с центральными системами, такими как System/390. Другой IOM станции обеспечивает подключение ПК, использующих протокол LU 6.2. В нашем примере необходимо соединение «точка-точка» с удаленной системой, заданной в операторе SQL CONNECT. Следовательно, мы будем использовать IOM станции для APPN. Этот IOM станции дополняет запрос управляющей информацией, необходимой для удаленной сессии. Он также обеспечивает интерфейс между FM и IOM линии.

IOM станции использует для данного соединения описание котроллера CTLD, в MI — CD. CD — это конфигурационный объект, содержащий информацию об удаленной системе (ее адрес, имя порта управления APPN и другие необходимые параметры). Руководствуясь информацией из CD, IOM станции добавляет к запросу ввода-вывода команды или необходимую управляющую информацию, а затем IOM станции посылает запрос ввода-вывода в очередь IOM линии.

IOM линии реализует протоколы канала. Он обеспечивает для IOM станции прозрачный интерфейс, не зависящий от нижележащего канального протокола и используемой сети. В нашем примере мы собираемся воспользоваться протоколом SDLC (synchronous data link communications).

IOM линии управляет передачей данных и определяет физические подключения к линии. Для этого он использует описание линии LIND, которому в MI соответствует описание сети ND, а для линии SDLC добавляет к запросу необходимые управляющие символы. IOM линии также обеспечивает интерфейс между верхними слоями коммуникационного протокола и аппаратным соединением.

Далее запрос передается средству связи между процессами IPCF, расположенному в SLIC. IPCF используется для всех устройств; оно взаимодействует с аппаратурой ввода-вывода для отправки запроса IOP на плате адаптера по шине SPD. С помощью LUD (DEVD указан в SSR) IPCF определяет, что в нашем примере используется модем, подсоединенный к плате адаптера, а та, в свою очередь, — к физической линии связи. Вскоре мы поговорим, как именно выполняется передача; но сначала нужно рассмотреть блоки управления вводом-выводом, позволяющие SLIC работать с аппаратурой.

Блоки управления ввода-вывода и связи между ними показаны на рисунке 10.3. Блоки содержат всю информацию, необходимую IPCF для поиска устройства. Эта информация в виде таблиц находится в памяти, где она доступна как аппаратуре, так и ПО, и обновляется во время загрузки системы, когда назначаются адреса IOBU. Обратите внимание, что стрелки на рисунке 10.3 соответствуют адресам, тогда как на рисунке 10.2 — передачам управления.