Фрэнк Солтис - Основы AS/400

Теперь 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.

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

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

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

Почему я так уверен в будущем AS/400? В этой главе мы рассмотрим ПО и аппаратуру версии 4, и Вы получите представление о ближайших перспективах этой системы. Глава 12 посвящена версиям AS/400, следующим после 4. И пусть пока трудно сказать что-то конкретное, но уже есть достаточно обоснованные предположения относительно новых технологий, которые изменят всю индустрию информатики в следующие 5-10 лет. Я намерен высказать свое мнение о том, как эти технологии повлияют на AS/400.

Конечно, всякие предположения — это лишь предположения. Мы живем в эпоху постоянных перемен, и создаем компьютерные технологии в соответствии с ее требованиями. Предсказывать будущее различных аппаратных и программных технологий легче легкого; тяжело лишь выбрать, какие из них подойдут для решения конкретных проблем. Разумеется, у IBM свои планы на этот счет, но так как они еще не устоялись, а также из соображений защиты интересов корпорации в конкурентной борьбе, я не буду обсуждать эти планы подробно. Но и не постесняюсь сделать определенные прогнозы насчет основных тенденций развития информатики и их влияния на AS/400.