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

Рисунок 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, несомненно, усвоили его уроки.

Глава 11

Версия 4

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

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

В компьютерной индустрии важную роль играет мода. Самый безошибочный, на мой взгляд, способ предсказать будущее — понаблюдать за тем, какие журналы читает Ваш босс в самолете. Если в каком-нибудь из этих журналов есть статья о новой вычислительной технике, то весьма велика вероятность, что скоро Вас попросят освоить эту модель. Никто не хочет отставать от моды! В этой главе мы поговорим о том, что в моде сегодня, и какие технологии лежат в основе этой моды.

Расширенная версия 4 AS/400

Как я уже говорил, версия 3 ознаменовала переход на RISC-процессоры. Отдельные версии OS/400 для CISC- и RISC-систем позволили заказчикам пользоваться старыми и новыми моделями с равной функциональностью. С объявлением в 1997 году версии 4, ситуация изменилась. Новые возможности этой версии будут реализованы только на RISC-моделях. Возможно, некоторых из новых функций будут доступны и на CISC-моделях, но IBM не будет больше эквивалентно поддерживать системы разных архитектур. Но, конечно, приложения, написанные для CISC-модели, в версии 4 работают по-прежнему без изменений, полностью используя возможности RISC-ап-паратуры.

С момента первого появления AS/400 в 1988 году, срок жизни версии OS/400 составлял три года. У каждой версии было разное число выпусков, но эта цифра оставалась неизменной. У меня нет причин сомневаться, то и версию 4 ждет та же судьба. Новые выпуски начались в 1997 году и, наверняка, будут продолжаться до 1999 года. Учитывая быстроту изменений в окружающем нас мире, вероятно, у версии 4 будет еще больше выпусков, чем у предыдущих. И если история повторится, то примерно к 2000 году можно ожидать или новой версии, или совершенно новой системы. В следующей главе я постараюсь спрогнозировать, что будет с AS/400 после 2000 года.

IBM вкладывает большие средства в развитие различных компонентов AS/400. На рисунке 11.1 показаны области связанных с электронным бизнесом капиталовложений в версию 4[ 80 ]. Эти инвестиции отражают предполагаемые направления развития компьютерной индустрии в соответствии с нуждами наших заказчиков в течение нескольких следующих лет. Они также указывают на те расширения, которые Вы можете ожидать в AS/400.

Рисунок 11.1. Поддержка е-бизнеса в AS/400

Итак, поговорим о перспективных направлениях развития AS/400. В этой главе мы рассмотрим:

три модели приложений — сетевые, совместные и клиент-серверные вычисления; два направления развития ПО — поддержку приложений и оптимизацию обработки данных;

две ветви развития аппаратных средств — расширения в старших моделях и улучшение соотношения цена-производительность.

Многих из этих тем мы уже так или иначе касались в предыдущих главах, и на них я не буду останавливаться подробно. Мы начнем с сетевых вычислений — модели приложений, которая сейчас привлекает наибольшее внимание.