Система ввода-вывода
Операции ввода-вывода в AS/400
Теперь от аппаратной архитектуры вводавывода AS/400 перейдем к совместной работе OS/400, SLIC и аппаратуры при выполнении операции ввода-вывода для прикладной программы. Сначала рассмотрим объекты, поддерживающие ввод-вывод, затем — многоуровневую структуру, включающую OS/400, SLIC и аппаратуру. А в заключение — проследим весь путь ввода-вывода от OS/400 до устройства и обратно.
Объекты поддержки ввода-вывода
Для поддержки вводавывода OS/400 и MI используют разные, но тесно взаимосвязанные объекты. В MI таких системных объектов три, в OS/400 — четыре. Проще всего рассмотреть эти объекты с точки зрения способов подключать устройства к AS/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.
Компоненты ввода-вывода
Думаю, Вас уже не удивляет, что ввод-вывод, как и практически все остальные компоненты AS/400, оперирует собственной терминологией и набором аббревиатур. Чтобы рассуждать о вводе-выводе, с этими обозначениями необходимо познакомиться. Список сокращений, которые я собираюсь использовать в своем рассказе, приведен в таблице 10.1. Это язык ввода-вывода.
Как уже говорилось, сегодня в устройствах ввода-вывода AS/400 все еще преобладает шина SPD. Поэтому рассказ о вводе-выводе в следующих разделах я буду иллюстрировать примерами именно для этой шины, при необходимости, отмечая существенные отличия с вводомвыводом по шине PCI. Впрочем, везде, за исключением самих нижних уровней SLIC, эти различия незначительны. Архитектура ввода-вывода AS/400 предназначена для работы с самыми разными интерфейсами, так что добавление в будущем новых интерфейсов окажет минимальное влияние на существующее системное ПО. И конечно, с точки зрения приложений никаких различий вообще нет; это гарантируется архитектурой, не зависящей от технологии.
Структура вводавывода SPD для AS/400, от MI до средства связи между процессами (IPCF) в SLIC, представлена на рисунке 10.2. В верхней части рисунка показан процесс MI — пример пользовательской прикладной программы, выполняющейся в системе.
В "Одноуровневая память" для пояснения к рассказу об одноуровневой памяти мы использовали похожий простой пример. Теперь расширим этот пример для иллюстрации операций ввода-вывода. Если Вы помните, тогда прикладная программа выполняла последовательное чтение индексированного файла базы данных, которое, могло быть выполнено либо с помощью команды "Read" ЯВУ, либо с помощью команды SQL "FETCH". Результатом в обоих случаях — запрос на выполнение операции вводавывода для считывания записи с диска. Чтобы сделать пример более интересным, предположим, что вместо считывания записи с диска, подключенного к локальной машине, нужно считать запись из удаленной системы на другом конце линии связи, используя для этого команду SQL.
В "Интегрированная база данных" мы говорили, что интерфейс 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 и аппаратурой. В нашем примере четыре слоя обработки, а именно:
Аппаратный уровень будет рассмотрен в следующем разделе.
В OS/400 может работать прикладная поддержка коммуникаций, предоставляемая как пользователем, так и IBM. Пользовательская поддержка коммуникаций подключается с помощью API, хотя, конечно, такой поддержкой обладает далеко не каждая прикладная программа. В нашем примере, прикладная поддержка предоставляется компонентом DRDA базы данных AS/400.
Менеджер функций (FM) — это компонент OS/400, предоставляющий интерфейс между приложениями и MI. Для каждого "транспорта" коммуникаций в SLIC обычно имеется соответствующий FM в OS/400. FM отвечает за верхние уровни протокола коммуникаций, например за то, чтобы данные были представлены приложению в той форме, в которой оно этого ожидает.
В нашем примере используется FM для механизма коммуникаций, называемого APPC (advanced programtoprogram communications). Впервые АРРС был реализован в System/38, где поддерживал параллельные сессии между системами, позволяя таким образом взаимодействовать нескольким приложениям на разных системах. При этом применялся коммуникационный протокол LU 6.2 (logical unit type 6.2). Порт для посылки и приема данных от приложения на другой системе предоставляло прикладной программе логическое устройство (logical unit).
В AS/400 этот механизм был расширен до уровня APPN (advanced peertopeer 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 — передачам управления.
Кроме того, на рисунке 10.3 показаны семь блоков управления. Давайте рассмотрим их подробней4Учтите, что приведенная в списке информация специфична для устройств, подключенных к шине SPD. Впрочем, реализация для PCI концептуально мало чем отличается от описанной..
- Управляющая адресная таблица (CAT) — эта общесистемная таблица, в которой содержатся адреса основных блоков управления, используемых SLIC.
- Очередь свободных сообщений (AMQ) — это очередь незаполненных сообщений, на которую указывает один из адресов в CAT. Сообщения из этой очереди могут использоваться различными компонентами SLIC, включая IPCF.
- Таблица управления шиной (BCT) содержит буферы, SRQ и указатели на другие блоки управления. На каждую шину SPD приходится по одной BCT.
- Блок устройства шины (BUB) содержит информацию о различных подключенных
к шине устройствах. На каждую шину SPD приходится по одному
BUB. Здесь размещается очередь сообщений ввода-вывода, ожидающих завершения
операции.Обратите внимание, что этот BUB не то же самое, что BUB (Bring Up Bind), о котором говорилось в "System Licensed Internal Code (SLIC) — сердце AS/400" . Тот BUB использовался для оценки прогресса в разработке SLIC, и, возможно, мне не следовало его упоминать, чтобы не путать читателей.
- Удаленный CCB (или удаленный CGCB) — имеется по одному для каждой шины SPD в системе, а также для каждого идентификатора подключения, назначенного IOBU. Этот управляющий блок хранит для удаленных (находящихся вне процессора) IOBU идентификаторы устройств, состояния и адресов IOBU. Некоторые IOBU могут поддерживать несколько устройств и, соответственно, иметь несколько идентификаторов подключения.
- Локальный CCB (или локальный CGCB) — один из этих блоков также имеется для каждой шины SPD в системе. Они очень похожи на удаленные блоки, но содержат информацию об IOBU, подключенных локально (внутри процессора).
- Блок управления подключениями (CCB) — один для всей системы. Он содержит идентификаторы подключений и маршруты для всех шин SPD, а также обеспечивает доступ к информации подключений для каждой отдельной шины.