Как все это работает

Как все это работает

В этом разделе мы продолжим разговор о вводе-выводе на примере шины SPD. Мы рассмотрим подробности низкоуровневых операций, выполняемых ниже IPCF и очень специфичных для структуры шины SPD, используемой как в старых, так и в новых моделях AS/400. Чтобы представить себе операцию ввода-вывода по SPD в целом, проследим ее с самого начала, когда приложение запрашивает выполнение ввода-вывода, и до момента получения приложением уведомления о завершении операции.

Иллюстрировать наш рассказ будет рисунок 10.4, представляющий собой несколько упрощенную версию рисунка 9.2. На нем показаны действия, выполняющиеся до посылки сообщения о начале операции («Opstart») по шине SPD соответствующему

IOP.

На рисунке изображена команда MI «REQIO», а также SPD и пользовательский буфер. Для простоты показан только один IOM. Как и раньше, запрос посылается в очередь IOM. Когда IOM завершает свою обработку, запрос на передачу («SENDREQ») отправляется IPCF. Именно здесь мы ранее остановились, рассматривая пример.

Для операции ввода-вывода IPCF создает две структуры данных. Первая — это сообщение запроса ввода-вывода (IORM), позволяющее IPCF отслеживать выполнение этого запроса и хранить информацию о его отправителе. Вторая структура данных — это блок управления запросом-ответом (RRCB). С его помощью IOP на плате адаптера SPD определяет тип запрошенной операции, расположение в памяти данных, которые должны быть считаны или записаны, а также то, куда следует поместить состояние завершения. Эта структура данных получает информацию от семи блоков управления, изображенных на рисунке 10.3

Форматы IORM и RRCB показаны на рисунке 10.5. Здесь также представлен формат двух сообщений шины SPD, используемых для начала и завершения операции ввода-вывода.

Рисунок 10.5 Структуры данных IPCF

Рисунок 10.4. Операция ввода-вывода (начало)

IORM — это сообщение, указывающее, кто запросил данную операцию ввода-вывода, или, точнее, кого следует уведомить о ее завершении. Поля сообщения задают его тип и адрес блока устройства шины. Этот адрес показывает, где расположен BUB для шины SPD, а также IOP для устройства, которому послан запрос. Данное сообщение будет поставлено в очередь, связанную с указанным BUB, на все время ожидания завершения ввода-вывода. Постановка в очередь означает, что IPCF сохраняет в BUB адрес данного IORM. В очереди одного BUB одновременно может находиться более одного IORM, то есть на шине SPD может одновременно быть несколько ожидающих операций.

В IORM также указан адрес очереди, куда будет послано сообщение по завершении ввода-вывода. Эта очередь связана с IOM, отправившим запрос IPCF. Перед посылкой сообщения в очередь IOM, поле состояния в IORM будет заполнено информацией о том, завершилась ли операция нормально или нет.

Последние два поля IORM — это идентификатор подключения CID и адрес RRCB. CID инициализируется IPCF с использованием блоков управления подключениями, рассмотренных в предыдущем разделе. CID уникально идентифицирует устройство. IPCF получает CID из удаленного блока управления подключением, используя информацию IORM. Адрес RRCB задает место расположения в памяти данного блока управления. Обратите внимание, что в этих блоках используются реальные, а не виртуальные адреса.

RRCB — это блок управления, от которого IOP получает подробную информацию об отправляемом запросе ввода-вывода. В отличие от блоков управления, инициализируемых во время загрузки системы, RRCB — это временный блок управления, который создается для каждого запроса ввода-вывода. RRCB может иметь переменную длину, так что первое поле задает размер блока в памяти. После поля длины следуют два поля, задающие CID (тот же, что и в IORM) и идентификатор RID, позволяющий различать запросы. Далее следует поле расширенного состояния, нужное, если возвращаемая информация состояния не умещается в поле состояния в IORM.

Остальные поля RRCB содержат адреса основной памяти. Первым идет адрес самого запроса ввода-вывода, за ним — адреса одного или нескольких буферов данных. В нашем примере запрос ввода-вывода — это команда модему, а не запрос на получение находящейся в буферах данных информации от удаленной вычислительной системы. Запрос ввода-вывода не записывается в RRCB, так как имеет разную длину для разных устройств, а находится в памяти по адресу, заданному этим полем. Буферы данных, на которые указывают следующие поля, содержат данные, подлежащие передаче на устройство. В нашем примере здесь будет размещаться адрес пользовательского буфера — SSD, в котором хранится запрос SQL к удаленной системе.

На рисунке 10.5 приведены также форматы двух сообщений шины: «OPSTART» и «OPEND». Это примеры 12-байтовых сообщений, посылаемых по шине SPD во время операций устройства, о которых говорилось выше. Первое сообщение, «OPSTART», используется в нашем примере для запуска операции ввода-вывода.

Сообщение «OPSTART» содержит четыре поля. В первом находится длина RRCB в памяти. Второе поле идентифицирует это сообщение как сообщение «OPSTART». Третье — занято адресом RRCB в памяти. Последнее поле содержит идентификатор подключения сервера. Сервером здесь выступает IOP, так что нам необходимо задать сервер для сообщения шины. Идентификатор подключения сервера — часть CID. Полный CID в RRCB задает устройство.

Для запуска операции ввода-вывода IPCF, используя операцию устройства, посылает сообщение «OPSTART» по соответствующей шине SPD указанному IOP на плате адаптера (до модема дело еще не дошло). При получении сообщения IOP инициирует операцию памяти на шине и, используя DMA, считывает в свою память весь RRCB. После получения RRCB IOP снова запускает операцию памяти для считывания из основной памяти запроса. Наконец, поскольку данная операция требует пересылки данных (нашего запроса SQL удаленному компьютеру) на устройство, IOP выбирает данные из буферов, которые содержат наш запрос SQL FETCH.

Теперь IOP выдает модему команду на посылку нашего запроса по линии связи на удаленный компьютер. Данные пересылаются из указанных буферов основной памяти. Когда операция завершается получением от удаленной системы сигнала об окончании приема, IOP формирует сообщение шины «OPEND». Затем он запускает операцию устройства для отправки сообщения «OPEND» обратно IOBU, в роли которого выступает системный процессор. Как Вы помните, в качестве IOBU выступают и IOP, и системный процессор.

Сообщение шины «OPEND», показанное на рисунке 10.5, содержит четыре поля. В первом находятся различные биты флагов, предоставляющие информацию об операции и ее завершении. Второе — поле типа — идентифицирует это сообщение как «OPEND». Третье поле содержит идентификатор запроса RID, который был ранее помещен IPCF в RRCB. Наконец, четвертое поле содержит состояние завершения. В зависимости от состояния флагов, информация завершения может также находиться в поле расширенного состояния RRCB.

Рисунок 10.6 иллюстрирует конец операции ввода-вывода из нашего примера. Получение сообщения «OPEND» означает, что IOP закончил обработку запроса. Обработчик ввода-вывода (не показан на рисунке) выводит IORM из очереди BUB для шины SPD, по которой было получено сообщение «OPEND», обновляет поле состояния и посылает IORM в очередь маршрутизатора IPCF.

Рисунок 10.6 Операция ввода-вывода (завершение)

Маршрутизатор IPCF проверяет состояние завершения, и если все нормально, посылает ответное сообщение в очередь, указанную в поле адреса очереди возврата IORM. IOM, отправивший запрос ввода-вывода, выполняет необходимую очистку и, если операция завершилась нормально, посылает запись отклика (FBR) в очередь ответов MI (MIRQ), которая была указана в оригинальном запросе источника-стока. Эта запись уведомляет менеджера функций о завершении первой операции ввода-вывода. На этом FM заканчивает операцию и может выполнять следующие. Приложение, запросившее SQL FETCH, будет ждать, пока удаленная система не возвратит результаты обращения к базе данных.

В результате только что описанной операции ввода-вывода наш запрос SQL был отправлен на удаленную систему. Когда запрос прибыл на удаленную систему, удаленный модем сообщил локальной системе о его получении. Затем модем удаленной системы запустил операцию ввода-вывода для приема запроса. Некоторое время спустя, когда база данных удаленной системы завершит выполнение нашего запроса, удаленная система инициирует операцию ввода-вывода для отправки нам результатов. IOP на локальной системе, к которому подключен модем, получит данные с удаленной системы и запустит другую операцию ввода-вывода. На этот раз IOP пошлет сообщение «OPSTART» центральному процессору, который, как мы видели выше, также может выполнять все функции IOBU. Когда MIRQ получит сообщение «OPEND» о завершении второй операции ввода-вывода на локальном компьютере, менеджер функции уведомит прикладную программу, что обработка ее запроса ввода-вывода (SQL FETCH) завершена.

Прежде чем закончить рассмотрение примера, хочу отметить, что для выполнения ввода-вывода требуется гораздо меньше времени, если для соединения систем используется OptiConnect, а не линия связи. Во-первых, системы соединены высокоскоростным оптоволоконным кабелем. Во-вторых, протоколы связи APPC и APPN заменяются специальным драйвером устройства. Этому драйверу не требуются сложные проверки для отслеживания ошибок, которые возможны при обмене данными по обычной линии связи, где сигналы обязательно содержат электрические шумы. Для проверки и исправления ошибок требуется передача избыточной информации. Передача информации по оптоволокну осуществляется с помощью света и свободна от шумов. Таким образом, драйвер устройства, используемый OptiConnect, обеспечивает прямое соединение c меньшей избыточностью.

Хочу особо отметить: если запрос SQL направляется локальной базе данных, то никакие из только что описанных операций, задействующих APPC FM, IOM станции APPN, или IOM станции SDLC, выполняться не будут. Вместо этого, поддержка базы данных локальной системы будет обрабатывать запрос SQL FETCH с использованием одноуровневой памяти так, как было описано в главе 8. Страничные ошибки, которые приводят к обращениям на диск, обрабатываются компонентом управления памятью, работающим напрямую с IPCF.