Основы AS/400
Шрифт:
Хочу еще раз напомнить, что в этом разделе мы обсуждаем только шину SPD. IOP PCI также управляют платами адаптеров, подключенных к шине PCI. Но так как шина PCI синхронна, и адаптеры не требуют установки собственных отдельных процессоров, то управление и протоколирование гораздо проще.
Операции ввода-вывода в AS/400
Теперь от аппаратной архитектуры ввода-вывода AS/400 перейдем к совместной работе OS/400, SLIC и аппаратуры при выполнении операции ввода-вывода для прикладной программы. Сначала рассмотрим объекты, поддерживающие ввод-вывод, затем — многоуровневую структуру, включающую OS/400, SLIC и аппаратуру. А в заключение — проследим весь путь ввода-вывода от OS/400 до устройства и обратно.
Объекты поддержки ввода-вывода
Для поддержки ввода-вывода OS/400
Устройство можно подключить непосредственно к плате адаптера ввода-вывода. Чтобы предоставить системе характеристики этого устройства, используется системный объект. Как Вы помните, MI не зависит от нижележащей аппаратуры, включая аппаратуру устройств ввода-вывода, поэтому необходимо логическое, а не физическое описание устройства. Другими словами, нужна информация о том, что некоторое устройство — это принтер, но формат потока данных для этого устройства требуется только на нижнем уровне системы, но не MI. Соответственно, системный объект, используемый MI для описания устройства, называется описанием логического устройства LUD (logical unit description). Эквивалентный объект OS/400 — описание устройства DEVD (device description).
Устройства не обязательно подсоединяются к адаптеру непосредственно. Они могут быть подключены к внешнему контроллеру, а через него — к плате адаптера. Иногда к контроллеру можно подключать несколько устройств, одного или разного типа, но обычно он специализирован для некоторого класса устройств. Например, есть котроллеры коммуникаций, дисков, принтеров и т. д. Системный объект, используемый для описания контроллера на уровне MI, называется описанием котроллера CD (controller description), а эквивалентный объект OS/400 — также описанием котроллера, но обозначается аббревиатурой CTLD (controller description).
Устройства и контроллеры могут подключаться к системе не только локально, но и удаленно с помощью разных типов связи. Системный объект MI для описания линии или сети называется описанием сетиND (network description). OS/400 использует как объект описание линии LIND (line description), так и объект описание сетевого интерфейса NETINTD (interface description).
OS/400 также рассматривает весь ввод/вывод как набор устройств источников-стоков. Вспомните, что OS/400 ничего не «знает» о дисках, а все элементы поверх MI рассматривает как объекты с памятью внутри. С точки зрения OS/400 устройство ввода-вывода — либо источник информации, поступающей в систему извне, либо сток информации, передаваемой из системы. Устройство никогда не используется для хранения информации в системе. Таким образом, весь дисковый ввод-вывод выполняется в SLIC ниже MI.
Компоненты ввода-вывода
4 Денис! Эту сноску — на поля! Таблица по старому изданию, сравнить с новым. Для верстальщика: по-моему, стоит убрать рамку — будет красивее
Таблица 10.1. Язык ввода-вывода
| AMQ | Очередь свободных сообщений |
| BCT | Таблица управления шиной |
| BCU | Устройство управления шиной |
| BTM | Механизм транспорта шины |
| BUB | Блок устройства шины |
| BUM | Сообщение устройства шины |
| CAT | Управляющая адресная таблица |
| CCB | Блок управления подключениями |
| CGCB | Блок управления группой подключений |
| CID | Идентификатор подключения |
| FBR | Запись отклика |
| IOBU | Устройство шины ввода-вывода (IOP) |
| IORM | Сообщение запроса ввода-вывода |
| IPCF | Средство связи между процессами |
| MIRQ | Очередь ответов MI |
| RID | Идентификатор запроса |
| RRCB | Блок управления запросом-ответом |
| SSD | Данные источника-стока |
| SSR | Запрос источника-стока |
Думаю, Вас уже не удивляет, что ввод-вывод, как и практически все остальные компоненты AS/400, оперирует собственной терминологией и набором аббревиатур. Чтобы рассуждать о вводе-выводе, с этими обозначениями4 необходимо познакомиться. Список сокращений, которые я собираюсь использовать в своем рассказе, приведен в таблице 10.1. Это язык ввода-вывода.
Как уже говорилось, сегодня в устройствах ввода-вывода 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).