Текст книги "Основы AS/400"

Автор книги: Фрэнк Солтис

сообщить о нарушении

Текущая страница: 32 (всего у книги 41 страниц)

Шина SPD

Итак, компьютеры серии AS/400е могут поддерживать шины SPD, PCI или обе одновременно. Шина PCI – промышленный стандарт и известна лучше, чем шина SPD, так что мы не будем тратить время на ее детальное описание. К тому же для большинства пользователей основным способом подключения устройств ввода-вывода к системе по-прежнему остается шина SPD, особенно на старших моделях, где поддерживается только она. Поэтому, прежде чем перейти к операциям ввода-вывода на AS/ 400, давайте рассмотрим шину SPD несколько подробнее.

Работу шины SPD обеспечивают платы ввода-вывода, показанные на рисунке 10.1. В терминологии первых моделей AS/400, каждая плата ввода-вывода предоставляет эквивалент устройства управления шиной BCU (bus control unit) для одной шины SPD в системе. К каждой шине может быть подключено до 32 адаптеров ввода-вывода SPD (на рисунке не показаны). Плата адаптера ввода-вывода SPD содержит IOP, а также соответствующую аппаратуру для подключения к системе одного или нескольких устройств.

Каждый IOP на плате адаптера ввода-вывода SPD имеет собственную память и собственную ОС. Эти специализированные ОС реального времени предназначены, в основном, для управления устройствами ввода-вывода. Очевидно, что приложение, выполняющееся на IOP, настроено на поддерживаемый IOP интерфейс конкретного устройства, коммуникационный или ЛВС. С точки зрения функционирования ввода-вывода, IOP, включая все его ПО, является устройством ввода-вывода на шине и называется IOBU (I/O bus unit). Таким образом, к шинам SPD подключаются IOBU, которые предоставляют интерфейс к устройствам ввода-вывода.

Как мы уже говорили в главе 8, для уникальной идентификации шины, IOBU и устройства процессор использует адрес прямого сохранения. IOBU получает команду от процессора системы, заставляет устройство выполнить запрошенную операцию и управляет всей передачей данных в основную память и обратно. По завершении операции ввода-вывода, IOBU передает системному процессору информацию, позволяющую определить, успешна ли операция.

Мы обсудим эти операции подробнее в следующих разделах. Давайте сначала рассмотрим способ физического соединения и некоторые характеристики перечисленных компонентов.

Соединения аппаратуры ввода-вывода SPD

Шина SPD работает асинхронно. Чтобы понять, почему был выбран именно этот вариант, вспомните кольцо SAN. Как отмечалось выше, синхронная шина требует, чтобы все подключенные к ней устройства работали с одинаковой тактовой частотой, что предполагает достаточно близкое расположение таких устройств. PCI – именно такая синхронная шина с тактовой частотой 33 МГц. Шины такого типа быстры и их адаптеры обычно дешевле адаптеров асинхронной шины, которые должны поддерживать собственную синхронизацию. Однако, поскольку асинхронная шина не тактирована, она допускает использование разнообразных устройств, размещенных на большем расстоянии и без угрозы искажения сигнала. Именно эта гибкость послужила причиной первоначального выбора для AS/400 асинхронной шины SPD.

В отличие от SAN, шина SPD не закольцована и должна использовать протокол. Такой протокол требует, чтобы передатчик и приемник начинали следующую операцию только после того, как оба они к этому готовы. Для этого шина имеет отдельные линии управления. Например, отправитель может установить на линиях управления запрос на считывание, а на линиях данных – адрес. Управляющие сигналы не снимаются до тех пор, пока приемник не подтвердит их получение, поместив сигнал на управляющую линию подтверждения.

К каждой шине SPD подключено как минимум два IOBU. И основной процессор, и контроллер устройства работают как IOBU. Таким образом, на шине SPD никогда не бывает только одного IOBU; ведь основной процессор – это IOBU, так же как и контроллер любого устройства. К одной шине SPD может быть подключено максимально до 32 IOBU. При подключении к шине нескольких IOBU необходим арбитраж, если два или более устройств захотят использовать ее одновременно. Для арбитража используется механизм приоритетности. Каждому IOBU назначается приоритет, определяющий, какой IOBU может использовать шину, если на это претендуют несколько устройств.

Прежде чем закончить эту тему и продолжить обсуждение ввода-вывода, следует отметить, что IOP можно использовать не только для функций управления вводом-выводом. Совершенно ясно, что IOP – это полноценный процессор со своей собственной ОС и прикладными программами. Он также имеет непосредственный доступ к основной памяти и, посредством шины ввода-вывода, к дисковой системе AS/ 400. Таким образом, IOP годится и для выполнения пользовательских приложений, и такая возможность интенсивно реализуется в AS/400. Подробнее об этом – в следующей главе.

Работа шины ввода-вывода SPD

Каждая плата ввода-вывода SPD предоставляет BCU для одной шины SPD. BCU осуществляет основное управление работой шины. Обычно BCU выполняет восстановление после ошибки и повторное выполнение операции. Он также проводит арбитраж, если несколько IOBU пытаются использовать шину одновременно.

Кроме того, BCU инициализирует шину при каждой загрузке системы, назначая подключенным IOBU логические адреса. Это означает, что к AS/400 может быть подключен новый IOBU, возможно, вместе с новым устройством. При перезагрузке системы новый IOBU конфигурируется автоматически, никакого вмешательства со стороны пользователя не требуется. Эта технология аналогична plug-and-play, применяемой в ПК.

Еще одна функция BCU – назначать каждому устройству приоритет шины. BCU проверяет способность каждого IOBU работать по шине и загружает код в память IOP.

При нормальной работе все коммуникации осуществляются между IOBU. Как говорилось выше, и в качестве IOBU, и в качестве всех IOP на платах адаптеров ввода-вывода SPD функционируют системные процессоры. Обмен информацией всегда происходит между IOBU, начавшим операцию шины (ведущим), и другим IOBU, который был выбран (ведомым).

• Информация передается между IOBU в форме сообщений фиксированной длины или операций прямого доступа к памяти DMA (direct memory access) переменной длины. Во многих вычислительных системах аппаратура DMA позволяет IOBU осуществлять блочную передачу определенного числа слов в основную память и обратно напрямую, без вмешательства процессора.

• Операцию шины можно определить как кратковременное соединение между двумя IOBU. Каждая такая операция шины состоит из двух частей. Сначала ведущий выбирает ведомого, а также определяет тип и направление передачи данных. Вторая часть операции состоит из тактов данных (от 1 до 16), во время которых происходит пересылка данных (за один такт —32 бита).

Шина SPD поддерживает два типа операций: операции устройств и операции памяти. При операции устройств сообщение передается от ведущего к ведомому. Длина сообщения всегда равна 12 байтам. Формат сообщений мы рассмотрим в следующем разделе.

Операция памяти позволяет осуществлять пересылку DMA между памятью IOP на плате адаптера и основной памятью системы. Пересылка управляется ведущим, который устанавливает соединение и определяет направление пересылки. Максимальное число байтов, пересылаемое за одну операцию памяти – 64 (4 байта за такт Г16 тактов данных = 64).

В ходе операции и системный процессор, и IOP могут функционировать и как ведущий, и как ведомый. При выполнении операции памяти системный процессор может быть как ведущим, так и ведомым, а IOP – только ведущим. Последнее ограничение означает, что данные никогда не пересылаются из памяти одного IOP в память другого IOP, то есть, что по шине SPD невозможен ввод-вывод типа «точка-точка». Следовательно, чтобы переслать, например, данные непосредственно от дискового IOP к IOP ленты, надо обязательно использовать основную память. Это снижает общую гибкость структуры системы.

Хочу еще раз напомнить, что в этом разделе мы обсуждаем только шину SPD. IOP PCI также управляют платами адаптеров, подключенных к шине PCI. Но так как шина PCI синхронна, и адаптеры не требуют установки собственных отдельных процессоров, то управление и протоколирование гораздо проще.

Операции ввода-вывода в 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.

Компоненты ввода-вывода

⁴ Денис! Эту сноску – на поля! Таблица по старому изданию, сравнить с новым. Для верстальщика: по-моему, стоит убрать рамку – будет красивее

Таблица 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).

В 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 – передачам управления.

CAT

Рисунок 10.3. Блок управления вводом-выводом

Кроме того, на рисунке 10.3 показаны семь блоков управления. Давайте рассмотрим их подробней[ 79 ]79
  Учтите, что приведенная в списке информация специфична для устройств, подключенных к шине SPD. Впрочем, реализация для PCI концептуально мало чем отличается от описанной.


[Закрыть].

1. Управляющая адресная таблица (CAT) – эта общесистемная таблица, в которой содержатся адреса основных блоков управления, используемых SLIC.

Очередь свободных сообщений (AMQ) – это очередь незаполненных сообщений, на которую указывает один из адресов в CAT. Сообщения из этой очереди могут использоваться различными компонентами SLIC, включая IPCF.

Таблица управления шиной (BCT) содержит буферы, SRQ и указатели на другие блоки управления. На каждую шину SPD приходится по одной BCT.

Блок устройства шины (BUB) содержит информацию о различных подключенных к шине устройствах. На каждую шину SPD приходится по одному BUB. Здесь размещается очередь сообщений ввода-вывода, ожидающих завершения операции.

Обратите внимание, что этот BUB не то же самое, что BUB (Bring Up Bind), о котором говорилось в главе 3. Тот BUB использовался для оценки прогресса в разработке SLIC, и, возможно, мне не следовало его упоминать, чтобы не путать читателей.

Удаленный CCB ( или удаленный CGCB) – имеется по одному для каждой шины SPD в системе, а также для каждого идентификатора подключения, назначенного IOBU. Этот управляющий блок хранит для удаленных (находящихся вне процессора) IOBU идентификаторы устройств, состояния и адресов IOBU. Некоторые IOBU могут поддерживать несколько устройств и, соответственно, иметь несколько идентификаторов подключения.

Локальный CCB (или локальный CGCB) – один из этих блоков также имеется для каждой шины SPD в системе. Они очень похожи на удаленные блоки, но содержат информацию об IOBU, подключенных локально (внутри процессора).

7.Блок управления подключениями (CCB) – один для всей системы. Он содержит

идентификаторы подключений и маршруты для всех шин SPD, а также обеспечивает доступ к информации подключений для каждой отдельной шины.