Основы AS/400

В 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.