Основы AS/400

В данном переводе второго издания книги "Основы AS/400" описаны практически все аспекты работы этой вычислительной системы: от используемых в ней новейших аппаратных и программных технологий до истории создания. Издание состоит из предисловия, введения, 12 глав, приложения и предметного указателя; содержит иллюстрации. Автор книги Фрэнк Солтис, сделавший академическую карьеру в области информатики, начиная с замысла System/38, является одним из ведущих специалистов по идеологии и архитектуре AS/400. Книга предназначена для широкого круга читателей: бизнесменов, менеджеров, руководителей подразделений, желающих понять, чем система или сервер AS/400e могут быть выгодны их бизнесу. Тем не менее, издание будет полезно и специалистам, которые хотят разобраться в мельчайших деталях. На русском языке публикуется впервые.

Фрэнк Солтис

Той, кого люблю уже более 33 лет — моей жене Сандре.

От автора

Рочестер— пожалуй, самое творческое подразделение корпорации IBM. Далеко не все сотрудники IBM согласятся с таким утверждением. Разумеется, работа в маленьком городке на краю прерий на юго-востоке Миннесоты не означает полной изолированности от остальной корпорации, но все же создает сложности в части признания заслуг. Мы, сотрудники подразделения IBM в Рочестере, не часто получали право голоса при определении перспектив развития корпорации. Но изолированность имеет и свои преимущества. Самое большое из них — возможность сосредоточиться на нуждах наших заказчиков. Год за годом преданные своему делу люди из Рочестера продолжали творить, и год за годом результаты этого творчества приносили IBM прибыль. Рочестер никогда не достигал больших побед в «битве прожектеров» в штаб-квартире IBM, но мы всегда выходили победителями в битве за заказчиков.

Секрет успехов Рочестера — в его людях. Мы здесь, потому что нам это нравится. Нравится жить и работать в маленьком городе, где, как гласят рекламные щиты, «зимы холодны, а компьютеры горячи». Для многих из нас Рочестер — это не просто остановка в пути, но станция назначения. Наверное, именно поэтому мы с таким трепетом относимся к результатам своего труда.

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

Конечно, наша работа не завершена. Во многих отношениях серия AS/400e — лишь первый шаг на новом пути, и еще далеко не удовлетворяет своих создателей. Книга Inside the AS/400 (первое издание), где было описано то новое, что было внесено при разработке версии 3, создавалась именно под этим углом зрения. В этом, втором, издании мы рассмотрим версию 4 и то, что будет после нее.

Замысел этой книги возник еще в 1985 году. Некоторые, в том числе Пол Конт (Paul Conte), написавший предисловие для обоих изданий, предлагали мне написать книгу о System/38 и истории этого проекта. С повторным рождением System/38 в виде AS/400 в 1988 году я начал писать книгу о разработке этих систем и людях, их создавших. С тех пор я постоянно исправлял рукопись. Пол и другие торопили меня с завершением «летописи», и просили поскорей поделиться историей Рочестера с остальным миром. Кое-что из той рукописи вошло в первое издание Inside the AS/400. Этот исторический экскурс имел столь положительные отклики, что я расширил его и включил как приложение в это, второе, издание.

В течение нескольких последних лет я с огромным удовольствием сотрудничаю с Duke Communications International (родительской компанией Duke Press и журнала NEWS/400). Дэйв Дюк (Dave Duke) и его сотрудники проделывают огромную работу по изданию журнала, книг и организации конференций. И когда пришла пора подыскивать издательство для этой книги, я, естественно, выбрал Duke Press. С самого начала со мной работал Дэйв Бернар (Dave Bernard), главный редактор Duke Press, благодаря которому и первое, и второе издание книги получились столь качественными.

Трудную работу редактора обоих изданий книги выполняла Шэрон Хэмм (Sharon Hamm). Ей приходилось обрабатывать бесконечные изменения, которые я вносил в рукопись, и в то же время удерживать меня и сотрудников издательства в рамках плана. Она прекрасно справилась с этой задачей. Спасибо, Шэрон; работа с тобой была удовольствием.

Над этим вторым изданием работала также Триш Фабион (Trish Faubion) — ведущий редактор Duke Press. В первый раз мне довелось сотрудничать с ней при написании статей для NEWS/400 (тогда она была ведущим редактором этого журнала). Триш занималась выпуском второго издания, составляла для нас план и помогала укладываться в него. Спасибо тебе, Триш, за твой вклад в создание этой книги.

Наибольший вклад в окончательное оформление обоих изданий внес был научный редактор Ричард Рубин (Richard Rubin). Ричард хорошо известен своими превосходными статьями, особенно в области проектирования баз данных. Я был склонен смотреть на AS/400 изнутри, Ричард же — с точки зрения пользователя. Всякий раз, когда я уносился в облака, прославляя какой-нибудь технический аспект AS/400, он спускал меня на землю вопросом: «Какой смысл это имеет для пользователя?» Благодаря тому, что Ричард почти везде настаивал на наличии примеров и проявлял внимание к деталям, текст стал гораздо понятнее широкому кругу читателей. Спасибо, Ричард.

Наконец, эта книга вообще не была бы написана без самого важного человека в моей жизни — Сандры, моей жены. Заметив мои затруднения в начале работы, Сандра помогала мне сортировать материалы и расшифровывать видеозаписи моих лекций по архитектуре AS/400. Эти расшифровки и составили черновой вариант книги. Во время работы над вторым изданием она продолжала играть роль «главного одобряющего», советчика, рецензента и редактора по совместительству. Спасибо тебе за то, что ты всегда была рядом.

Сандра и я — счастливые родители трех прекрасных сыновей: Майка, Брайана и Стива. Читателям первого издания известно, что мне вместе с сыновьями нравится водить гоночный Порше по дорогам Среднего Запада. Я сожалением должен признать, что Порше был самым заброшенным членом семьи в этом году. Всякий раз, когда я проходил мимо гаража, оттуда прямо-таки слышались его мольбы покататься. Раньше, когда я бывал слишком занят, эту обязанность принимали на себя мои сыновья. Но в этом году они тоже были слишком заняты собственными семьями и карьерой. Так что моей бедной машине оставалось лишь ждать, пока я закончу эту книгу. Но, что это? Я слышу доносящийся из гаража рев гоночного автомобиля. Кто-то зовет меня!

— F.S.

Предисловие

IBM AS/400 — одна из самых интересных по инженерным решениям и эффективных коммерчески компьютерных архитектур. Задолго до того, как термин «объектно-ориентированный» широко распространился, машинный интерфейс высокого уровня AS/400, появившийся в предшествовавшей ей System/38, предоставил разработчикам приложений набор объектов (таких как очереди, индексы и файлы базы данных), которые при создании программы можно было использовать в качестве строительных блоков. Объекты придали высоким функциональным возможностям системы согласованную и простую в работе форму. Унифицированный объектный интерфейс скрывает от программистов AS/400 детали, благодаря чему они могут игнорировать сложные управляющие блоки и системные процедуры, относящиеся к внутренним процессам операционной системы (ОС). Более того, с помощью набора заранее определенных операций ОС ограничивает доступ к объектам. Это обеспечивает приложениям дополнительную защиту при исполнении.

Объекты AS/400 расположены в слое программного обеспечения поверх аппаратных средств. Это позволяет IBM вносить в аппаратуру значительные изменения, не затрагивая при этом приложения. Обычно новое оборудование требует лишь обновления поставляемого IBM внутреннего кода — ведь интерфейсы объектов, задействованных приложениями, неизменны. Это еще одно преимущество объектов AS/400: они позволяют приложениям воспользоваться новшествами аппаратных средств, при этом модифицировать код приложений не требуется. Все детали реализации системных объектов «скрыты» слоем программного обеспечения.

Можно сказать, что архитектура AS/400 «балует» программистов — где еще Вы найдете подобную рациональность? И все же программисты любят знать, как работает системное программное обеспечение, и те, кто работает с AS/400 s не исключение. На любой конференции по AS/400 они обычно собираются группами и растолковывают друг другу, какова сущность внутренних процессов системы, что происходит при активизации программного объекта, переопределении файла при его открытии или выполнении какой-нибудь другой операции. Дело, конечно, не просто в неудовлетворенном любопытстве; во многих случаях глубокое понимание архитектуры AS/400 позволяет программисту писать более функциональный или эффективный код. Но любому опытному программисту известно, что только по руководствам всего не узнаешь. Это особенно справедливо для AS/400, руководства по которой специально лишены описания деталей внутренней структуры или функционирования.

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

Конечно, мой интерес (я думаю, это относится и к другим разработчикам) не ограничивается только текущими техническими подробностями. Хочется больше знать и об истории такой совершенной системы, и о людях, давших ей жизнь, и, конечно, о перспективах AS/400.

Автор этой книги, Фрэнк Солтис — именно тот человек, кто действительно «изнутри» знает все это, и может компетентно рассказать о создании AS/400, использованных в ней технологиях и планах IBM. Сам Фрэнк — одна из центральных фигур повествования: с момента появления замысла System/38 он играл ключевые роли в эволюции архитектуры AS/400. Его опыт охватывает несколько основных эпох организационного и технологического развития IBM, ему приходилось отвечать и за аппаратуру, и за программное обеспечение и за организационные вопросы. Фрэнк сочетает в себе таланты инженера и системного архитектора, да к тому же сделал академическую карьеру в области информатики. Добавьте к этому незаурядный миннесотский юмор, и вот результат s чтение разделов, посвященных, к примеру, «тегированной памяти» или «очереди распределения задач», становится захватывающим.

Сейчас, когда мы переживаем бум Интернета, Web-узлов, языка Java и распределенных вычислений, очень интересно узнать, какие новые возможности AS/400 позволяют ей претендовать на роль «лучшего из серверов». В этом, втором, издании своей книги Фрэнк объясняет, каким образом новая архитектура RISC, а также существенные усовершенствования в OS/400 и SLIC (System Licensed Internal Code) позволяют обеспечить дополнительные возможности и лучшее соотношение цена/производительность для всего модельного ряда AS/400 — от систем начального уровня до мощных кластеров, обрабатывающих миллионы транзакций в час. Поистине, нет человека, который мог бы сделать это лучше.

Я впервые встретился с Фрэнком в 1985 году. Тогда я только что познакомился с System/38 после многих лет работы на мэйнфреймах IBM, и эта система была для меня новой и интересной. Фрэнк произвел на меня впечатление обычного «IBM'ера» — он часами рассуждал о технических деталях архитектуры, уделяя при этом большое внимание «человеческому фактору». Он был таким интересным и толковым рассказчиком, что я принялся убеждать его написать об System/38 книгу. Позднее я узнал, что именно тогда руководству IBM, будущее System/38 представлялось весьма туманным. Понятно, что Фрэнк не хотел рассказывать историю, пока не убедился, что у нее будет счастливый конец. Теперь же огромный успех AS/400, широта ее распространения и ключевая роль в стратегии IBM позволяют Фрэнку поделиться своими знаниями. Счастливого Вам путешествия по AS/400 с гидом, о котором можно только мечтать!

Пол Конт.

Президент, Picante Software, Inc.

Введение

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

Однажды бывший президент США Гарри С. Трумен (Harry S. Truman) сказал: «В мире нет ничего нового, за исключением истории, которой Вы не знаете». Чтобы до конца понять, как работает любая вычислительная система, необходимо изучить ее историю, а также понять людей, ее создавших. Особенно верно это для такой системы, как AS/400, которая, как мне кажется, не вписывается в общие рамки.

На дизайн вычислительной системы значительное влияние оказывает то, в рамках какой организации она была создана, и то, какие продукты ей предшествовали. Если группе разработчиков удалось нечто успешное, то на следующем цикле проектирования она «изобретет» это заново и вместо новой системы построит улучшенную модель существующей. Радикально новые идеи обычно приходят извне.

Возьмем проекты, создававшиеся на протяжении многих лет компьютерными фирмами восточного побережья США. Как правило, их ключевые концепции были заимствованы из исследований, выполненных в учебных заведениях типа Массачу-сетского технологического института MIT (Massachusetts Institute of Technology). В 60-х годах инженеры и ученые MIT под патронажем Министерства обороны США работали над проектом МШг^. Впоследствии и IBM, и другие компании нанимали выпускников этих университетов для создания новых операционных систем. Так как проектировщики имели сходный опыт, то и созданные ими системы оказались очень похожими. Такие операционные системы как ОС MVS для мэйнфреймов IBM, ОС VMS корпорации Digital Equipment и все ОС Unix — имеют общие «восточно-университетские» корни.

Даже новая ОС — Windows NT фирмы Microsoft — несет в себе черты того же самого прошлого. Команда, создавшая Windows NT, ранее работала над ОС VMS компании Digital, в результате многие элементы Windows NT «навеяны» VMS. Если Вы замените буквы аббревиатуры VMS на следующие за ними буквы английского алфавита, то получите WNT, и это не просто случайность. История AS/400 совершенно иная.

Менее года назад я был в Буэнос-Айресе на встрече с группой пользователей этой системы. По окончании встречи молодой репортер газеты «La Nacion» спросил меня: «Сформулируйте, пожалуйста, коротко причины того, почему в AS/400 столь много новшеств?». И я ответил: «Потому что никто из ее создателей не заканчивал MIT.» Заинтригованный моим ответом, репортер попросил разъяснений. Я сказал, что не собирался критиковать MIT, а лишь имел в виду то, что разработчики AS/400 имели совершенно иной опыт, нежели выпускники MIT. Так как всегда было трудно заставить кого-либо переехать с восточного побережья в 70-тысячный миннесотский городок, в лаборатории IBM в Рочестере практически не оказалось выпускников университетов, расположенных на востоке США. И создатели AS/400 — представители «школ» Среднего Запада — не были так сильно привязаны к проектным решениям, используемым другими компаниями.

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

Начало

В 50-х годах XIX века группа фермеров Новой Англии поселилась в Рочестере (Rochester), штат Миннесота. Вероятно, Рочестер и сейчас был бы маленьким сонным фермерским городком, если бы не торнадо 1883 года, от которого пострадали многие жители. Врач Уильям Уоралл Мэйо (William Worall Mayo), в то время гостивший здесь у приятеля, лечил раненых. Он так и остался в Рочестере, а позже к нему присоединились два его сына — Уильям в 1883 году и Чарльз в 1888. Принятое ими в 1889 году решение — открыть частную больницу, которую они назвали клиникой Мэйо, — превратило Рочестер, в конце концов, в международный медицинский центр. Сейчас здесь один врач на 70 жителей, чистая окружающая среда, замечательная система образования и низкий уровень преступности. По данным журнала «Money», Рочестер год за годом входит в двойку или тройку лучших мест страны для проживания.

А самое важное для нас то, что Рочестер — колыбель AS/400. В 1956 году IBM, в то время нью-йоркская компания с несколькими производственными и проектными филиалами в разных городах этого штата, объявила о создании нового подразделения в Рочестере. Томас Дж. Уотсон-старший (Thomas J. Watson, Sr.), основатель IBM, прожил большую часть жизни в Нью-Йорке и предпочитал размещать новые филиалы именно там. Решение выйти за пределы штата Нью-Йорк означало для IBM отказ от имиджа местной компании.

Впервые я приехал в Рочестер в 1962 году, за год до открытия там проектной лаборатории. Тогда я еще учился в университете, и IBM предложила мне работу на лето в Рочестере. В то время меня не привлекали ни компьютеры, ни тем более жизнь в маленьком степном городе на юге Миннесоты — я грезил авиакосмической индустрией Калифорнии. Но я был знаком с менеджером проекта в Рочестере и думал, что мне будет приятно поработать с ним летом.

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

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

Через год, окончив университет, я вернулся в Рочестер и стал работать под началом того же руководителя проекта. В течение следующих нескольких лет подразделение IBM в Рочестере перешло к разработке компьютеров, и я принял в этом участие. Затем, мне вновь предложили поучиться: я был одним из многих инженеров, имевших весьма ограниченные познания в области операционных систем. Недостаток знаний о вычислительных архитектурах и проектировании операционных систем я возмещал в Университете штата Айова (Iowa State University).

Я вернулся в Рочестер в конце 1968 года со степенью доктора и некоторыми вполне сложившимися идеями о том, как следует проектировать новую компьютерную систему. Вскоре, в июне 1969 года, был объявлен первый компьютер Рочестера

System/3. System/3 была продукцией специального назначения и более походила на счетную машину, чем на компьютер. Я не понимал тогда, что разработчикам из Роче-стера удалось попасть в компьютерный бизнес, лишь создав в штаб-квартире IBM иллюзию, что они делают счетную машину. В конечном счете это не сыграло большой роли, так как System/3 было суждено стать нашим первым успехом, залогом будущей революции в компьютерной индустрии.

В течение 1969 года я работал над проектом, в ходе которого мне удалось «отшлифовать» многие из идей, почерпнутых в университете. В конце 1969 года я получил новое задание — разработать архитектуру для наследника System/3.

Революция начинается

В пронизывающе холодный вторник 8 января 1970 года я[ 1 ] представил руководству Рочестера предложения по революционно новой компьютерной архитектуре, основой которой был машинный интерфейс высокого уровня. Примененную в этой архитектуре структуру адресации, названную одноуровневой памятью, я позаимствовал и развил из собственной докторской диссертации. Основной мотив — защитить капиталовложения заказчиков в прикладные программы, сделав вычислительную систему независимой от нижележащих аппаратных технологий. Новая система должна была совершенно отличаться от System/3, но, несмотря на это, содержать большую часть функций последней. Эта способность поддерживать среду System/3 оказалась крайне полезной годы спустя, когда нам понадобилось соединить эти две линии.

Не испугавшись поистине радикальных идей, лежавших в основе новой архитектуры, руководство Рочестера решило принять эти предложения и создать специальную группу для разработки новой системы. В течение шести месяцев была создана группа из девяти человек, которая должна была превратить мечты в реальность. Я стал архитектором новой системы. Вряд ли я понимал тогда, что буду оставаться в этой роли более четверти столетия.

Подразделение Advanced Systems, сформированное для создания новой системы, действовало изолированно от разработки System/3 (семейство System/3 продолжало расти, и к нему добавились System/32 в 1975 году и System/34 в 1977). До середины 70-х новым проектом занималось не так уж много сотрудников, но затем сотни и тысячи людей со всей IBM присоединились к нашей команде. 24 октября 1978 года мы объявили о создании новой системы. Она была названа System/38.

System/38 была немедленно объявлена компьютером с расширенной архитектурой — одна из крупнейших инноваций IBM за долгие годы. Очень немногие люди, как внутри IBM, так и вне корпорации, по-настоящему поняли, что произошло. Но среди тех, кто осознал мощь и потенциал System/38, быстро сформировалось нечто, похожее на культ. Встречи групп пользователей часто походили на религиозные собрания.

Однако System/38 не заменила семейство System/3, как мы изначально надеялись. Новая система не привлекла многих наших старых заказчиков. Первые продажи System/38 были задержаны до июля 1980 года, как мы объявили, из-за недостаточной производительности. На самом деле, самая большая проблема производительности заключалась в том, что система не работала сколь-нибудь продолжительное время перед сбоем. Эта задержка отпугнула некоторых заказчиков. Кроме того, владельцы меньших систем — System/32 и System/34 — нашли, что новая система слишком велика и слишком дорога. Удовлетворить потребности большинства таких заказчиков смог объявленный в мае 1983 был последний вариант System/3 — System/36. Так что разработки компьютеров в Рочестере по-прежнему шли в двух разных направлениях.

Проект Fort Knox

В начале восьмидесятых IBM решила объединить пять ранее несовместимых линий продукции IBM, включая две из Рочестера, в новой интегрированной системе, названной Fort Knox. Ставилась цель: владельцы всех пяти типов машин должны были иметь возможность перенести свои приложения на эту единую систему. Разработка Fort Knox началась в четырех разных лабораториях IBM с больших инвестиций.

В 1985 году стало ясно, что проект Fort Knox зашел в тупик. У нас, в Рочестере, многие считали его нежизнеспособным с самого начала, так как он был призван разрешить проблемы IBM, а не потребителей. Было и такое мнение: проект слишком сложен технически, нет способа преобразовать пять разных систем в одну. И, кроме того, совместной работой четырех лабораторий управлять почти невозможно. По всем указанным причинам, Fort Knox потерпел неудачу, и IBM его закрыла.

Fort Knox «высосал» большинство ресурсов, которые иначе были бы направлены на System/36 и System/38. А без инвестиций трудно было поддерживать конкурентоспособность обеих систем. IBM зашла настолько далеко, что объявила System/38 «не стратегической» и не рекомендовала клиентам приобретать ее.

Ранняя AS/400 (она же System/38)

В конце 1985 небольшая группа разработчиков из Рочестера продемонстрировала, что на System/38 можно создать среду для программного обеспечения System/36. Стоимость оборудования снизилась настолько, что мы теперь могли создавать малые модели System/38. Это означало, что мы могли «закрыть» весь диапазон продукции Рочестера. Быстро последовало предложение: объединить две системы в одной машине, основанной на System/38. Мы назвали новую машину Silverlake[ 2 ] и убедили руководство IBM, что можем ее создать.

Снова Рочестер показал IBM и всему компьютерному миру, на что способен. После беспрецедентного 28-месячного цикла разработки, мы объявили о новой, объединенной, системе под названием AS/400. Посвященные, однако, знали, что внутри каждой AS/400 скрывается System/38[ 3 ].

Успех AS/400 превзошел все ожидания. Очень быстро она не только «отвоевала» часть рынка, захваченную конкурентами в предыдущие годы, но и быстро обошла их всех. Ныне во всем мире работает более 500 000 систем AS/400, что делает ее бестселлером среди многопользовательских вычислительных систем. Культ System/38 стал полноценной религией.

В 1991 Apple Computer, Motorola и IBM достигли исторического соглашения по разработке нового семейства процессоров. Эти процессоры должны были использовать архитектуру RISC и применяться везде, от ручных устройств до суперкомпьютеров. Новые процессоры, названные PowerPC, были призваны потрясти компьютерный мир.

В это время Рочестер искал новую архитектуру процессора для следующего поколения AS/400. Это должен был быть первый полностью новый процессор по сравнению с 1978, использовавшимся в оригинальной System/38. И мы подумали: почему бы не объединить силы с альянсом PowerPC, чтобы создать для AS/400 новый процессор, основанный на этой архитектуре?

Союз AS/400-PowerPC

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

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

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

Часто задают вопросы: «Как появилась AS/400?», «Кто эти люди, называющие себя ее создателями?». Далее я постараюсь ответить на них.

Команда технических разработчиков

В IBM разработка любой новой продукции осуществляется командой, каждый из участников которой вносит в дело свой вклад. По правде говоря, успех проекта обычно определяют всего несколько человек. Это инженеры и администраторы — лидеры, обладающие предвидением, творческими способностями и энергией. Своим созданием и успехом как System/38, так и AS/400 обязаны именно таким людям.

В Рочестере много хороших инженеров и администраторов, но лишь несколько истинных провидцев. Дальновидный лидер способен не только сознавать перспективы проводимых работ, но и донести свое видение до других. Затем идея начинает жить собственной жизнью, и приобретать некие реальные очертания. Теперь дело лидера — поощрение тех, кто старательно и успешно работает над различными частями проекта.

В 1972 году я по-прежнему все еще пытался увлечь наших разработчиков радикальными концепциями архитектуры System/38. Большинство технических специалистов успешно трудились над созданием новой аппаратуры, «не ведая, что творят». Они полагали, что просто разрабатывают некое новое программное обеспечение для уже существующей системы. (Формат внутренних команд System/38 был очень похож на используемый в System/370.) Это был единственный способ задействовать людей так, чтобы они чувствовали себя комфортно, не подозревая, что делают нечто необычное[ 4 ].

Прорыв на фронте программного обеспечения тогда достигнут не был. Большинство программистов в Рочестере написали улучшенные версии программного обеспечения System/3. Они чувствовали себя вполне комфортно и не желали никаких революций в области архитектуры.

Именно в это время на передовую линию создания полной архитектуры вышли два человека. Они помогли мне убедить все сообщество разработчиков в том, что мы находимся на правильном пути. Дик Бэйнс (Dick Bains) и Рой Хоффман (Roy Hoffman) — одни из наиболее творческих, обладающих истинным даром предвидения людей, которых я когда-либо встречал. Они также отличаются истинной преданностью идее. В течение 1972 мы втроем завершили спецификацию архитектуры AS/400, и хотя в последующие годы некоторое детали претерпели изменения, в целом концепция осталась неизменной.

У Дика — талант в области технологии компиляторов и языков. Его опыт стал решающим при определении машинного интерфейса высокого уровня и внутреннего транслятора.

Дик вырос в соседнем штате Висконсин, до начала работы на IBM в Рочесте-ре, попробовал себя в нескольких ролях, одно время даже был инструктором по лыжам в Эспине (Aspen), штат Колорадо. И всякий раз, когда при разработке спецификации архитектуры у нас возникали затруднения, он начинал вздыхать по более легкой жизни лыжного инструктора. По счастью, Дик не поддался этому стремлению.

Дик каждый раз так увлекался решением проблемы, что мог действовать, не задумываясь о последствиях. Например, годом ранее, он пытался убедить руководство в несовершенстве защиты некоторых местных компьютерных систем. Когда никто не захотел его слушать, Дик решил продемонстрировать проблему наглядно. Войдя в систему, допуска к которой он не имел, он оставил там сообщение с предложением позвонить ему, если те, кто несет ответственность за защиту системы, захотят закрыть «дыру». При этом он умудрился нечаянно попортить несколько файлов. Вся эта история чуть не стоила Дику места, но к счастью для всех нас, руководство признало его талант и он не был уволен. Более того, ему удалось доказать свою правоту.

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

У Роя уже в те времена был накоплен солидный опыт в области компьютерных архитектур и проектирования операционных систем. Его вклад в разработку архитектуры System/38 — особенно в области низкоуровневых функций операционной системы — обеспечил ей успех.

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

Рою нет равных в решении технических проблем. Его познания в области вычислительных систем огромны, он способен атаковать проблему с позиций, недоступных большинству из нас. Его свежий взгляд часто помогал найти красивое техническое решение. (На самом деле Рой пошел дальше. Он часто давал окружающим и личные советы, нужны они нам были или нет. Меня по-прежнему забавляет, с каким удовольствием он стремится проанализировать ситуацию и дать мне какой-нибудь дикий совет по воспитанию детей или по другому предмету, в котором абсолютно несведущ.) После завершения работы над System/38, Рой возглавлял некоторые передовые технические проекты Рочестера. Он также работал над новыми технологиями для всей IBM. Рой был членом IBM Academy, где помогал определять направления технического развития всей корпорации. В 1994 году Рой ушел на пенсию. Сейчас он как раз закончил книгу о сжатии данных, и в погожие дни Вы по-прежнему можете увидеть, как он гоняет на своем «Харлей-Дэвидсоне».

Не ясно как, но этот союз лыжного тренера, «рокера» и автомобильного фаната достиг успехов в компьютерной области. К концу 1972 разработка новой архитектуры была завершена. В последующие годы Дик, Рой и я часто собирались для обсуждения изменений и новых идей. До настоящего дня я удивляюсь, как много из того, что мы совместно вложили в систему, другие открывают только сейчас.

Рочестеру повезло со специалистами. В пользу этого суждения говорят многие инновации как в аппаратном, так и в программном обеспечении. Однако никто другой не обладал таким видением системы и ее перспектив, как Дик и Рой. И как и очень многие другие узкие специалисты, чья работа не видна непосвященным, эти двое никогда не получали того признания, которое заслужили.

Команда менеджеров

Ни одна система не «пойдет» только благодаря удачному инженерному решению; без хорошего управления тоже не обойтись. На мой взгляд, успех System/38 и AS/400 обеспечили пятеро менеджеров, лучше других увидевшие их перспективы. Но один из пяти заслуживает признания более, чем остальные: Гарри Ташиян (Harry Tashjian). Это он, осознав потребность в небольшой, простой в использовании деловой системе, и создал новый рынок для компьютеров. Без его дара предвидения не было бы успеха наших компьютеров.

Гарри был главной организующей силой проектов System/3, System/32, System/34, System/36 и System/38. Сначала он выполнял функции системного менеджера (system manager) всех этих продуктов, позднее стал директором Рочестерской лаборатории. Именно благодаря Гарри крошечное подразделение IBM, затерянное среди кукурузных полей Миннесоты, стало мировым лидером в разработке деловых компьютерных систем.

Гарри Ташиян — тот самый менеджер проекта банковского терминала, много лет назад склонивший меня к работе с компьютерами. До сих пор помню наши долгие разговоры о потенциале Рочестера в разработке новых вычислительных систем. Гарри «благословил» меня на новое путешествие в университет для изучения компьютерных архитектур, а когда я опять вернулся в Рочестер, именно он назначил меня на разработку архитектуры System/38, которой суждено было превратиться в AS/400, и обеспечил мне поддержку. Без Гарри AS/400 не было бы.

Успех System/38 обеспечили еще два менеджера. Рей Клотц (Ray Klotz) был нашим техническим менеджером (engineering manager) и моим боссом на протяжении большей части проекта. В 1970 году Гарри поручил Рею создать команду из 9 человек. Хорошо разбираясь в аппаратном обеспечении, Рей курировал создание процессора System/360 в Эндикотте (Endicott), штат Нью-Йорк, прежде чем пришел в Рочес-тер, чтобы возглавить разработку аппаратуры System/3.

Сначала Рей относился к System/38 сдержаннее, чем многие из нас. Он иногда напоминал, что все аппаратное обеспечение System/3 насчитывало лишь 3 000 цепей, и спрашивал, почему нам нужно настолько больше. Он продолжал сомневаться в наших технических решениях до тех пор, пока не приходил к убеждению, что мы рассмотрели все возможные варианты. Затем он давал нам «карт-бланш». Всякий раз, когда мы испытывали трудности, он был рядом, чтобы поддержать и помочь найти выход.

Для большинства из нас Рей был кем-то вроде отца. Мы все вздрагивали, когда он повышал голос, что бывало часто. Он требовал от каждого из нас безупречной работы и обычно добивался своего. Но за грубоватой внешностью Рея скрывался удивительно тонкий человек.

Из всех моих знакомых Гейлорд Гленн Хенри (Gaylord Glenn Henry) — самый выдающийся и совершенно неистовый менеджер.

Сказать, что Гленн не вполне вписывался в образ типичного, консервативного менеджера IBM, — не сказать ничего. Неряшливая борода, часто нелепая одежда и неизменные упаковки по шесть розовых банок какой-то диетической «шипучки» свидетельствовали о том, что перед Вами незаурядная личность.

В 1972 году Гленн перешел к нам из лаборатории IBM в Бока Ратон (Boca Raton), штат Флорида, и стал менеджером по программированию (programming manager) для System/32, а затем и System/38. Сильный и целеустремленный человек, он вдохновлял окружающих, увлекал за собой как разработчиков, так и администраторов. Когда нам казалось, что возникшая проблема непреодолима, Гленн убеждал нас, что все держит под контролем. Вскоре как-то само собой появлялось решение, а Гленн лишь улыбался. Без его таланта и дальновидности разработка System/38 могла быть прекращена множество раз.

Я еще не упомянул о соревновании по крепости голосовых связок между ° о Гленном и Реем. Если они не были согласны друг с другом, стены дрожали.

Было истинным удовольствием наблюдать за их спорами, особенно зная, что I ни тот, ни другой не понимают по-настоящему того, за что ратуют. Иногда к их спору присоединялся Гарри, но чаще он позволял Гленну и Рею улаживать свои разногласия самостоятельно. Однако все были согласны между ■ собой в одном: мы собираемся создать вычислительную систему, лучшую из когда-либо существовавших в мире. Наградой этим волевым личностям стала System/38.

К сожалению, после окончания работ над System/38 мы расстались с этими людьми. Гарри Ташиян оставил Рочестер, чтобы возглавить создаваемую IBM новую компанию — Discovision. После этого он занимал в IBM другие руководящие посты, прежде чем ушел на пенсию, имея 38 лет стажа.

Гленна перевели в Остин (Austin), штат Техас, где он возглавил разработку PC-RT. Он оставил IBM в 1988 году после 21 года работы, возмущенный неспособностью организации воспринимать новые идеи. Не удивительно, что некоторые из этих идей только сейчас реализованы в продукции IBM. Убежден, что уход Гленна был большой потерей для корпорации.

Но печальней всего была утрата Рея. Он умер вскоре после объявления System/38 и так и не узнал, чем стала его система для всего компьютерного мира. Никто и никогда не сможет занять его место.

В последнюю минуту

В начале 80-х годов из-за недальновидного руководства развитие вычислительной техники Рочестера стало спотыкаться. Однако у нас все еще было несколько хороших менеджеров, понимавших значение создаваемых систем. Этим людям приходилось поддерживать жизнь наших проектов зачастую весьма хитрыми способами. Казалось, у нас нет перспектив, и наши позиции на рынке окончательно будут завоеваны конкурентами. По счастью, в последнюю минуту появился человек, спасший Ротчестер от глубокого забвения. Его звали Том Фьюри (Tom Furey).

Том всегда был отличным продавцом. Он знал работу IBM изнутри и ухитрился убедить руководство, что системы Рочестера имеют стратегическое значение для будущего корпорации. Затем он начал «накачивать» нас приложить все мыслимые усилия и еще чуть-чуть, чтобы выпустить новую систему в рекордно короткие сроки.

Том хорошо знал рынок и требования заказчиков. Он преобразовал Рочестер из организации, управляемой техническими идеями, в организацию, движимую требованиями рынка. Прежде всего, он добился, чтобы наши заказчики были напрямую вовлечены в разработку. Совещания пользователей играли важную роль при выборе вариантов проектирования, а в результате получилась система, которую многие из них чувствовали своей. Позднее, Рочестер выиграл престижную премию Malcolm Baldrige National Quality Award за эту разработку.

Часто по-настоящему оцениваешь человека, лишь вглядываясь в него из будущего. Том никогда не был силен по части техники, как некоторые из его предшественников, и многие в лаборатории не принимали его как лидера, под тем предлогом, что Том до конца не может проникнуть в суть того, что они делают. Он и не мог, ну и что? Например, Том никогда не понимал, что AS/400 — это переупакованная System/38; а если и понимал, то никому не говорил об этом. Зато он убеждал всех и вся за пределами Рочестера, что это совершенно новая система, и ему верили.

Своим скорым коммерческим успехом AS/400, несомненно, обязана Тому. Он организовал массированный выход на рынок этого продукта IBM в масштабах, беспрецедентных со времен System/360. В итоге AS/400 выдвинулась на передние позиции среди коммерческих многопользовательских систем. После Рочестера Том перебрался в Санта-Терезу (Santa Teresa), штат Калифорния, где занял должность генерального менеджера разработки базы данных IBM DB/2. Позднее он стал генеральным менеджером IBM по клиент-серверным системам. Сегодня Том возглавляет проекты IBM, связанные с Олимпийскими Играми.

Твердая рука

После перехода Тома на новую работу в Калифорнии, мы потеряли значительную часть рынка. Несмотря на то, что нам досталась награда Malcolm Baldrige National Quality Award за учет требований рынка, руководство лаборатории тянуло нас назад к работе, ориентированный на удачные технические, но не коммерческие решения. Совещания заказчиков прекратились, а вместе с ними и прямой вклад пользователей в проектирование, чего удалось добиться Тому. Наше новое руководство состояло из бывших разработчиков и чувствовало себя не в своей тарелке, когда пользователи вмешивались в принятие проектных решений.

Единственным замечательным исключением на общем печальном фоне была наша программа Partners in Development (PID). Ей занималась группа энтузиастов, первоначально под руководством Джима Келли (Jim Kelly). Их усилия сосредоточилась на поддержке сообщества бизнес-партнеров AS/400 во всем мире, которые занимались разработкой и продажей большей части прикладного ПО, использовавшегося нашими заказчиками. Эти люди заслуживают самой большой похвалы за наш успех в данной области.

Подразделение AS/400 не утратило ориентированности на рынок благодаря еще одному человеку — Биллу Цайтлеру (Bill Zeitler). Билл был помощником генерального менеджера по маркетингу примерно с момента выхода первой системы до конца 1995 года, когда он получил назначение в Азию на 15 месяцев. За эти годы до момента временного ухода Билла в нашем подразделении сменилось пять генеральных менед-жеров5. Каждый из этих руководителей внес определенный вклад в успех AS/400, но именно твердая рука Билла направляла наш корабль в бурных водах рынка.

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

Так что без Билла и его команды AS/400 не смогла бы занять свое нынешнее положение на рынке. По счастью, по окончании командировки в Азию, Билл возвратился к нам в качестве генерального менеджера, чтобы запустить в разработку серию AS/400е.

Зачем написана книга?

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

Вы, возможно, уже поняли, что я чувствую себя обязанным включить в книгу кое-какую историческую информацию. Несколько лет назад я неформально унаследовал пост историка Рочестера от Карла Гебхардта (Carl Gebhardt), занимавшего его изначально. Карл был бизнес-менеджером (business manager) наших ранних систем, а позже, в бытность Гарри Ташияна директором лаборатории, работал системным менеджером и System/34, и System/38. Карл отвечал за финансовый успех ранних систем Рочестера. Я работал у него в начале 80-х, когда Карл был нашим директором по стратегии (director of strategy). Долгие годы Карл был историографом Рочестера. Он часто так и представлялся (официально такого поста не было, но мы оба считали, что он должен быть). Если возникал вопрос о чем-нибудь, что произошло несколько лет назад, Карл в большинстве случаев знал на него ответ. Когда Карл оставил работу, мы обсуждали, кто должен занять этот почетный пост, и он сдал вахту мне.

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

Хочу подчеркнуть: я излагаю в книге свою точку зрения. Я откровенный фанатик AS/400. Мои взгляды не обязательно совпадают с официальными позициями корпорации IBM. Надеюсь, чтение книги доставит Вам такое же удовольствие, как мне — ее создание.

Замечания ко второму изданию

Когда в 1994 году была объявлена Advanced Series, в Рочестере также выпустили первую версию новой операционной системы, которую назвали версией 3 V3R1 (Version 3 Release 1). Мы заявили, что собираемся изменить архитектуру процессоров на RISC, но системное ПО для обоих архитектур останется функционально эквивалентным, чтобы упростить переход под RISC. В 1995 году вместе с первыми RISC-моделями мы представили V3R6, которая должна была обеспечить функциональную совместимость с V3R1. В 1996 году появились расширенные версии обоих этих ПО: V3R2 и V3R7. Таким образом, Version 3 может рассматриваться как промежуточная операционная система на период перехода пользователей на новые RISC-модели.

Выход серии AS/400е в 1997 году вместе с OS/400 версии 4 (V4) был вехой, означающей конец периода перехода на RISC. Выпуски этой новой версии (V4R1, V4R2, V4R3 и т. д.) будут работать только RISC-моделях AS/400. Конкретно, OS/400 V4 работает на некоторых моделях Advanced Series (RISC-моделях) и на всех моделях серии AS/400e.

Если внешние интерфейсы RISC и не-RISC систем очень похожи, то этого нельзя сказать об их внутреннем устройстве. Некоторые внутренние компоненты одинаковы, другие же сильно отличаются. В этой книге, описывающей внутреннее устройство AS/400, невозможно полностью рассмотреть оба дизайна; для этого потребовалось бы две разные книги. Но вместо того, чтобы просто рассматривать только RISC-системы, я решил, там где это имеет смысл, также описать и некоторые подробности устройства не-RISC систем. Такое решение вызвано двумя причинами:

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

Многие части не-RISC систем по-прежнему имеют значение: либо их компоненты будут перенесены в будущие проекты, либо переход на новый дизайн только начался. Примером последнего служит ввод-вывод, новая архитектура которого только начала создаваться (подробнее об этом — в главе 10).

Во всех случаях, я пытался ясно указать, где обсуждаются решения для RISC, а где нет. Теперь о содержании книги:

Глава 1 посвящена идеям, лежащим в основе расширенной архитектуры AS/400. Здесь также обсуждается интеграция и ее значение для заказчиков.

В главе 2 рассматривается самый низкий уровень системы AS/400 — архитектура процессора. В этой главе обсуждаются только RISC-процессоры (в том числе и то, как они появились).

В главе 3 дается описание внутреннего системного ПО AS/400, известного как System Licensed Internal Code (SLIC), и опять только RISC-систем.

Тема главы 4 — машинный интерфейс MI. MI практически одинаков и для RISC- или для не-RISC-систем, но я включил в свой рассказ описание дополнительных команд для RISC-систем.

Глава 5 посвящена объектам AS/400 и управлению ими. Все, что сказано здесь, применимо и к RISC-, и к не-RISC-системам.

В главе 6 описывается интегрированная реляционная база данных AS/400 и внутренняя структура системы.

Глава 7 посвящена защите от несанкционированного доступа, включая становящуюся все более важной защиту в сетях.

В главе 8 рассматривается одноуровневая память AS/400. Основное внимание уделено реализации для RISC-систем, но я включил в текст достаточно информации о варианте для не-RISC, чтобы обосновать необходимость произведенных изменений.

В главе 9 описана структура управления процессами AS/400. Большая часть сведений применима как к RISC-, так и к не-RISC-системам.

Глава 10 посвящена системе ввода-вывода. Вначале рассматривается существующий ввод-вывод для не-RISC систем, затем — изменения в структуре ввода-вывода, реализованные в серии AS/400е.

Глава 11 переходит от рассмотрения отдельных компонентов системы к расширениям версии 4, а также тем, которые могут появиться в ближайшем будущем. Значительная часть обсуждения версии 4 посвящена электронному бизнесу, так как он имеет наибольшее влияние на будущий дизайн AS/400.

Наконец, в главе 12 мы попробуем предугадать, что ожидает AS/400 в следующем столетии.

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

OS/400 версии 4 и аппаратура серии AS/400e — наш взгляд на то, как лучше использовать возможности интеграции AS/400 в электронном бизнесе. Под электронным бизнесом мы понимаем безопасный, гибкий и интегрированный подход, принятие решений с помощью комбинации систем и процессов, исполняющих базовые деловые функции. Простоту и доступность такого нового подхода к делу обеспечивают технологии Интернета и World Wide Web (WWW).

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

Многие годы AS/400 — производительная, работоспособная, надежно защищенная система для традиционных и клиент-серверных приложений. Теперь мы даем своим заказчикам возможность применить эти ее замечательные свойства в мире электронного бизнеса.

Как читать эту книгу

Допускаю, что сам факт подобных рекомендаций может показаться читателю странным, но на то есть веские причины. Предполагаемая аудитория достаточно широка: от деловых людей, желающих понять, чем система или сервер AS/400е могут быть выгодны их бизнесу, до «спецов», которые хотят разобраться в мельчайших деталях. Я долго ломал голову, как «потрафить» и тем, и другим, намеревался даже разбить книгу на две части: обзор для обычных читателей и технические детали для «профи». Но как быть с теми, кому интересно все? Думал я и о том, чтобы снабдить книгу указателем, по которому и менеджер, и разработчик приложений, и студент, и любитель подробностей могли бы найти разделы, предназначенные специально для них. Но такая классификация слишком условна; всякий раз, когда я читаю какую-нибудь книгу в соответствии с подобным «путеводителем», мне самому трудно ориентироваться, какие разделы читать, а какие — пропустить.

Не знаю, чем закончились бы мои мучения, если бы не Малколм Хейнес (Malcolm Haines) из Лондона — одна из самых светлых голов в IBM. Малколма часто называют «министром пропаганды:» IBM UK, в его обязанности входит реклама IBM через видео-и коммерческие спутниковые телесети. Его компакт-диск «The Case Against the AS/ 400» — гениальный образчик британского юмора.

Именно Малколм посоветовал пометить наиболее трудные разделы — а там уж пусть читатель сам решит, читать их или нет. Еще он предложил использовать для обозначения степени сложности раздела перчик чили. Почему, это особая история. В прошлом году Малколм повел меня в англо-индийский ресторан Chutney Mary в Лондоне. Так вот, в меню этого уютного заведения картинки красного перчика чили обозначали остроту блюд — чем больше перчиков, тем острее. И Малколма осенило: почему бы не обозначить так же «остроту» технических разделов книги?!

Вот как выглядит в результате мой «гастрономический» рейтинг:

Отсутствие перчиков означает, что, с точки зрения технических подробностей, раздел довольно «пресный». Кое-что, конечно, есть, но любому читателю стоит добавить чуточку специй.

Один перчик — «техники» побольше. Это уровень, так сказать, массового читателя. Попробуйте, — а вдруг Вам придется по вкусу?

Два перца означают, что здесь определенно рассматриваются технические проблемы. И если для Вас это слишком, листайте до менее «острого» раздела.

Три чили — ау, любители острых блюд и ощущений! «Спецы» хищно улыбаются, утирая со лба пот. Не исключено, что при слишком внимательном чтении кто-нибудь почувствует запах жареного. Что тут посоветовать? На всякий случай держите под рукой стакан с водой или совсем пропустите подобный раздел.

Приятного аппетита!

Глава 1

Расширенная архитектура приложений

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

Общеизвестно, что у AS/400 прогрессивная, самая адаптируемая архитектура в мире, и что новые технологии не повлияют негативно на бизнес заказчиков этой системы. Да, это правда. Пользователям AS/400 не требуется «подгонять» свои прикладные программы под новые технологии. Однако, зачастую сами клиенты не понимают (или не хотят понимать) как работает система. Работает — и ладно!

Недавно архитектура AS/400 снова оказалась в центре внимания. AS/400 стала первой и единственной в мире системой, завершившей переход к 64-разрядным вычислениям. В новой модели был использован тип архитектуры процессора с сокращенным набором команд — RISC (reduced instruction set computer). Для сравнения: процессоры, использовавшиеся в исходной AS/400, а также другие популярные процессоры, такие как Intel Pentium или Intel Pentium Pro, используют архитектуру со сложным набором команд — CISC (complex instruction set computer). Главное достоинство RISC-архитектуры — более простые команды, чем у CISC. Это позволяет создавать процессоры, отличающиеся поразительной быстротой вычислений и за приемлемую цену. Последние версии RISC-процессоров всех производителей — 64-разрядные.

Проектирование и создание такой аппаратуры — не самая сложная проблема компьютерной индустрии. А вот как предоставить существующему программному обеспечению (ПО) возможность воспользоваться преимуществами новой аппаратуры? AS/400 — единственная система, где эта проблема решена. Все ее приложения используют 64-разрядные вычисления в полной мере.

Никакая другая система такими возможностями не обладает. Когда другие производители компьютеров переходили с CISC- на RISC-процессоры, это вызывало серьезные проблемы у их заказчиков и независимых производителей програмно-го обеспечения ISV (Independent Software Vendor), которым приходилось переписывать некоторые прикладные программы или их фрагменты. Так случилось, например, когда фирма Hewlett Packard объявила о своей архитектуре PA (Precision Architecture), или когда Digital Equipment Corporation (Digital) представила архитектуру Alpha.

Чтобы лучше понять масштаб проблемы, остановимся подробнее на попытке перехода на RISC, предпринятой фирмой Digital. По собственной оценке Digital перевод имеющегося парка на архитектуру Alpha вызовет необходимость переписать от 15 до 20 процентов старого кода приложений, предназначенных для архитектуры VAX. Любому заказчику или ISV такая модификация влетит в копеечку.

Архитектура AS/400, напротив, защищает пользователей системы и ISV от этих проблем при переходе на новые 64-разрядные RISC-процессоры. Существующие приложения сразу же в полной мере используют новые возможности аппаратуры.

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

Архитектура компьютера

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

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

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

С точки зрения программиста

В 1970 году С. С. Хассон (S. S. Husson) определил термин «архитектура компьютера» как «характеристики (вычислительной) системы с точки зрения программиста»[ 5 ]. Архитектура включает в себя набор команд, типы данных, операции ввода-вывода и другие характеристики. Иногда эти компоненты рассматриваются по отдельности, и тогда говорят об архитектуре наборов команд и архитектуре ввода-вывода. Архитектура в целом включает в себя все, что нужно знать программисту для создания корректно работающих программ.

С точки зрения аппаратуры у компьютера имеется пять основных компонентов: ввод, вывод, память, тракт данных (datapath) и устройство управления. Два последних компонента часто объединяют и называют процессором. Архитектура компьютера определяет, какие операции могут выполнять эти компоненты. Процессор выбирает данные и команды из памяти. Аппаратура ввода записывает данные в память, а аппаратура вывода — считывает из нее. Управляющая аппаратура генерирует сигналы, управляющие трактом данных, памятью, вводом и выводом.

Иногда процессор называют ЦПУ — центральным процессорным устройством CPU (central processing unit). В последнее время этот термин используется реже, так как современные технологии позволяют упаковать целый процессор в одну микросхему. Процессор, выполненный на одной микросхеме, обычно называют микропроцессором. Достаточно часто термины «ЦПУ», «процессор» и «микропроцессор» используют как эквивалентные. Однако, следует помнить, что не всякий процессор умещается на одной микросхеме — их может потребоваться несколько.

Если два компьютера могут выполнять один и тот же набор команд, то говорят, что у них одинаковая архитектура набора команд. Одна и та же архитектура может быть реализована по-разному. Так, например, архитектура Intel x86[ 6 ], применяемая во многих ПК, используется целым семейством микропроцессоров, созданных с помощью разных технологий и имеющих разную производительность. То есть конкретная технология, использованная при создании компьютера, не есть часть его архитектуры.

Уровни абстракции

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

На самом нижнем уровне — электронных схем — компьютер очень прост. Электронная схема понимает только две команды: включено и выключено, символически обозначаемые при помощи цифр 1 и 0. На данном уровне общение с машиной идет с помощью цепочек нулей и единиц. Команда — это понятный процессору набор двоичных цифр или битов (разрядов). Таким образом, команда представляет собой просто число в двоичной системе счисления или двоичное число. Компьютеры называются цифровыми, потому что на машинном языке для обозначения как команд, так и данных используются цифры.

Когда-то давно, программисты «общались» с компьютерами на языке двоичных чисел. Это не слишком удобно, поэтому был изобретен более высокий уровень абстракции — язык ассемблера, представляющий собой символическую форму двоичного языка компьютера. Ассемблером называется программа, транслирующая символическое представление команд в двоичную форму.

Для большинства программистов язык ассемблера — также не вполне естественный, поэтому был создан еще более высокий уровень абстракции — язык программирования высокого уровня (ЯВУ). В настоящее время насчитываются сотни таких языков; наиболее известные из них — Basic, C, C++, Cobol и RPG. Программа, принимающая на входе текст на одном из языков высокого уровня и транслирующая его в операторы языка ассемблера, называется компилятором.

Иллюстрация многоуровневой абстракции — написание программы на языке высокого уровня. Компилятор выполняет преобразование программы на ЯВУ в язык ассемблера, который затем переводит свои команды в двоичный код, понятный процессору. Замечу, что некоторые компиляторы генерируют команды непосредственно на машинном языке, минуя уровень ассемблера.

Перед выполнением программы на ЯВУ компилятор и ассемблер транслируют ее в команды машинного языка. Эта операция выполняется однократно, и при новом запуске программы повторять ее не надо, если только исходный текст программы не изменился. Наличие нескольких уровней позволяет скрыть детали нижележащего машинного языка от программиста и обеспечить более простой и производительный интерфейс.

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

Похожа на эмуляцию интерпретация программ. Программа-интерпретатор выбирает инструкции по одной и исполняет эквивалентную им последовательность команд более низкого уровня. Некоторые из новейших ЯВУ, используемых в распределенных вычислениях, например Java, разработаны так, чтобы их было легко интерпретировать. Большинство командных языков также интерпретируемы. Введите «dir» в командной строке DOS на любом ПК и на экране появится содержимое каталога. Если после этого нажать клавишу Enter, интерпретатор командной строки DOS считает введенную команду, а затем выполнит последовательность инструкций, необходимых для ее выполнения. Такой интерпретатор команд есть в большинстве операционных систем. В микропрограммируемой машине интерпретация обычно поддерживается специальным оборудованием. Микропрограмма для различения такой аппаратной формы интерпретации называется эмулятором.

Обычно архитектура набора команд вычислительной системы рассматривается как интерфейс между аппаратурой и программным обеспечением самого нижнего уровня. В те времена, когда Хассон сформулировал упоминавшееся выше определение архитектуры компьютера, программирование еще не использовало ЯВУ. Сегодня, более подходящим определением этого понятия было бы «характеристики системы с точки зрения компилятора», так как из нынешних программистов лишь немногие имеют дело с программами в машинных кодах.

С учетом многих уровней абстракции, более точно было бы говорить, что компьютер имеет несколько архитектур, хотя архитектура двоичного набора команд в большинстве случаев по-прежнему играет основную роль. Когда говорят, что один компьютер способен выполнять программы, написанные для другого компьютера без изменений, то обычно имеют в виду, что первый может выполнять двоичные коды (binaries) другого, и следовательно, для переноса программ с первого на второй их повторная компиляция не требуется. Иначе говоря, двоичный машинный язык одного компьютера непосредственно поддерживается другим компьютером.

Создание программ

Программное обеспечение любой вычислительной системы можно условно разделить на два типа: системное и прикладное. Примеры системного программного обеспечения — операционные системы, ассемблеры и компиляторы. Прикладное же программное обеспечение обычно предназначается непосредственно для пользователей и решает конкретные задачи.

Ранее считалось, что доступ к архитектуре самого нижнего уровня посредством ассемблера необходим как системному, так и прикладному программисту. В пользу этого суждения приводилось множество аргументов: большинство программ имели доступ к крайне незначительному объему памяти, процессоры были медленными и дорогими, а компиляторы с языков высокого уровня — не слишком хорошими. Когда нужно было «выжать последний грамм» для повышения производительности компьютера, «настоящие» программисты использовали язык ассемблера.

Теперь же появилось много приверженцев мнения, что программирование на языке ассемблера — реликт прошлого. Но это не так. Большинство используемых ныне операционных систем (не только старых, чьи корни которых восходят к 60-м и началу 70-х годов, но и более современных) включают в себя большие объемы кода на ассемблере. Таковы, например, операционные системы для ПК: Windows 95 фирмы Microsoft написана по большей части на языке ассемблера Intel.

Первые процессоры для ПК имели достаточно ограниченные возможности. Максимальный размер памяти был равен 64 килобайтам. (Один килобайт равен 210 или 1024 байтам. Байт — это 8-разрядная ячейка памяти, в которой может храниться символ или цифра). Память стоила настолько дорого, что операционные системы могли занимать не более 4 килобайт. Язык ассемблера позволял программистам максимально сокращать размер кода. В результате на нем написан такой большой объем операционных систем, что даже когда размер доступной памяти увеличился благодаря удешевлению технологии, возвращаться назад и переписывать оригинальный код оказалось непрактичным.

Использование ассемблера действительно позволяет оптимизировать размеры и производительность программ. Тем не менее, у этой технологии, по крайней мере, один существенный недостаток: все программы напрямую привязаны к аппаратуре. Любое ее изменение может вызвать необходимость переписать некоторые или даже все программы.

В качестве примера такой ситуации рассмотрим компьютер, имеющий восемь регистров. Регистр — часть тракта данных процессора. Это быстродействующая область памяти, куда помещаются данные и адреса на время их использования процессором. Основное назначение регистров — повышение производительности работы программ. Предположим, что ширина каждого регистра — 16 разрядов, и что программист может помещать данные в регистры и выбирать их оттуда в любой момент по своему усмотрению. Число регистров и их характеристики программист видит из ассемблера. Таким образом, каждая программа для данного компьютера, написанная на этом языке, будет «знать» о восьми регистрах и зависеть от них.

Теперь предположим, что технологический прогресс позволил конструкторам увеличить количество регистров до 16 и сделать их 32-разрядными, причем стоит все это столько же, сколько и оригинальные 8 регистров меньшего размера. Зададимся вопросом: «Как это повлияет на программы, написанные для старого компьютера?». Ответ зависит от того, каким образом были сделаны изменения, и сколь хорошо первоначальная архитектура была спланирована для расширения в будущем.

Допустим, что в старой архитектуре предполагалось расширение до 16 регистров. В каждой команде было зарезервировано достаточно места для адресации 16 регистров, хотя первоначально были реализованы только 8. Для каждой команды, использующей регистры, в данном случае понадобились бы 4-разрядные поля, так как 4 бита позволяют закодировать 16 различных комбинаций нулей и единиц. На новом оборудовании старые программы могут выполняться без изменений. При этом они по-прежнему будут использовать только 8 регистров, новые же программы смогут воспользоваться всеми 16-ю.

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

Одна из многих архитектур, неспособных увеличить число пользовательских регистров, — Intel Pentium Pro. Она использует то же количество регистров, что и ее предшественник Intel 386. Хотя увеличение числа регистров дало бы Pentium Pro преимущества, но затраты на переписывание существующих ассемблерных программ слишком велики.

Вообще, увеличение размера регистров с 16 до 32 разрядов оказывает меньшее влияние, чем изменение их количества. Если увеличился только размер, то старые программы будут по-прежнему работать, но использовать лишь 16 из 32 разрядов новых регистров. Данная информация внедрена в логику программы, и ее трудно изменить[ 7 ].

И подобных примеров, когда широко применяемые программы не способны использовать все ресурсы оборудования, — несметное множество. Процессор Intel 386, появившийся еще в 1985 году, имел 32-разрядный дизайн, то есть размер его аппаратных регистров был равен 32 битам. С того времени все процессоры Intel, включая 486, Pentium, Pentium II и Pentium Pro — 32-разрядные. Однако и большинство программ для ПК, использующих эти процессоры, и операционная система DOS были созданы в те времена, когда был доступен только 16-разрядный процессор Intel 286. Даже операционная система Windows 95 написана в основном на 16-разрядном ассемблере. На переписывание прикладных и системных программ ПК под 32-разрядную аппаратуру ушло уже 12 лет, и процесс все еще не завершен.

Эта проблема не ограничивается только индустрией ПК. Прогресс аппаратных технологий поднял планку еще выше: большинство новых процессоров будут 64-разрядными. Чтобы воспользоваться этим более мощным оборудованием, большинство современных 32-разрядных операционных систем и 32-разрядных прикладных программ должны быть переписаны. А это опять долгие годы работы.

В рассмотренных выше примерах модификации аппаратуры состояли в изменении размера и числа регистров процессора. Учтите, что аналогичное влияние на программное обеспечение, написанное на ассемблере, могут оказать и изменения в структуре адресации процессора или в самом наборе команд.

Основная цель программирования только на языках высокого уровня — минимизировать изменения в программах, вызываемые подобными модификациями аппаратуры. К сожалению, в системном программном обеспечении явно наблюдается тенденция перехода на языки, подобные С и С++. Использование С позволяет повысить переносимость системного программного обеспечения, так как компиляторы для этого языка есть на многих аппаратных платформах, но не устраняет все сложности, связанные с изменениями в оборудовании. Некоторые аппаратные характеристики, например разрядность процессора, видимы программисту на С. Такая возможность доступа к внутренним характеристикам привлекательна для системных программистов и объясняет популярность С. Это язык называют «современным ассемблером». В обычной вычислительной системе переход, например, с 32-разрядного процессора на 64-разрядный по-прежнему будет требовать изменений в программе на С. А это снижает переносимость С-программ.

Для иллюстрации рассмотрим опыт Digital. Последние несколько лет эта фирма продает свои машины с 64-разрядным процессором Alpha. Однако две основные операционные системы, используемые на этих компьютерах — Open VMS самой Digital и Windows NT фирмы Microsoft — все еще 32-разрядные, хотя и написаны, в основном, на С. Приложения для этих операционных систем, также 32-разрядные. Простая перекомпиляция здесь не поможет. Чтобы задействовать все ресурсы процессора, и операционные системы, и приложения надо полностью переписать, и это займет много лет.

HP также загнала покупателей своей HP 9000 в трясину переделок. Сейчас HP продает 64-разрядные версии своих процессоров PA-RISC. Чтобы воспользоваться преимуществами новых аппаратных средств, заказчикам HP придется ждать появления новой 64-разрядной ОС, и затем переписывать свои приложения. На это потребуется столько времени, что уже теперь, задолго до того, как переделка ПО будет завершена (см. главу 12), есть признаки того, что HP может отказаться от дальнейшей разработки HP 9000.

Секрет успешного перехода к 64-разрядным вычислениям на AS/400, в то время как никому больше это не удалось, кроется в ее архитектуре.

Классификация архитектур

Принципов классификации компьютерных архитектур немало. Вероятно, самый старый из них — по формату команд процессора. Другой, уже знакомый, — разделение процессоров на категории CISC и RISC. Оба эти подхода учитывают только аппаратный интерфейс процессора. С точки же зрения заказчика прикладные программы гораздо важнее. Следовательно, не менее законно будет классифицировать компьютерные архитектуры по способу взаимодействия прикладных программ с аппаратным интерфейсом.

Процессоро-ориентированная архитектура

Подавляющее большинство используемых ныне компьютерных архитектур основаны на традиционном подходе, открывающем программисту аппаратный интерфейс. Такие архитектуры называются процессоро-ориентированными (processor-centric) потому, что аппаратный интерфейс в них видим прикладным программам и используется последними непосредственно. Примеры процессоро-ориентированных архитектур — PA фирмы HP и Alpha фирмы Digital.

API-ориентированные архитектуры

Учитывая недостатки процессоро-ориентированных архитектур, многие ISV, производители оборудования и организации по стандартизации совместно разрабатывали архитектуры, в основе которых лежит интерфейс прикладных программ API[ 8 ] (application programming interface). Такие API-ориентированные архитектурыустанавливают коммуникационный барьер — интерфейс, который используется всем прикладными программами для доступа к сервисам операционной системы и изолирует их от аппаратных и программных деталей.

Операционная система — это набор программ, управляющих системными ресурсами и служащих фундаментом для написания прикладных программ. Часто таким фундаментом становятся API. Существуют различные формы реализации API. Это может быть вызов или команда, запрашивающая у операционной системы согласие на выполнение некоторых действий. Хорошо известный пример API — функция операционной системы, вызываемая прикладной программой для выполнения операции ввода-вывода, такой как чтение с диска. Очевидно, что прикладной программе незачем «знать» подробности внутренней работы ввода-вывода. Программы операционной системы, выполняющие функции ввода-вывода и часто называемые подсистемами ввода-вывода, изолируют приложения от деталей аппаратной и программной реализации. Приложения, использующие для выполнения ввода-вывода только соответствующие API, не зависят от каких-либо изменений в структуре ввода-вывода на нижних уровнях.

Дополнительное преимущество дает реализация разными производителями одного и того же набора API. В этом случае приложения легко переносить с одной системы на другую. Один из наиболее известных стандартных наборов API — POSIX. POSIX — сокращение, неформально расшифровываемое как «переносимый интерфейс операционной системы базирующейся на Unix» (portable operating system interface based on Unix) — это набор международных стандартов для интерфейсов Unix-подоб-ных операционных систем. Правительственные и неправительственные организации поощряют реализацию производителями Unix-подобных операционных систем данных стандартов, как обеспечивающую переносимость приложений с одной системы на другую.

Общая проблема стандартов типа POSIX состоит в том, что они никогда не становятся законченными, и стадия определения такого стандарта занимает многие годы. В такой ситуации разработчики приложений часто берут дело в свои руки. В 1993 году группа разработчиков приложений для Unix и производителей Unix-подобных операционных систем решила определить свой собственный набор API. Они не могли ждать, пока спецификация POSIX «созреет» до такой степени, чтобы ее можно было использовать. Кроме того, ясно, что когда спецификация POSIX будет, наконец, полностью завершена, все приложения придется переписывать под новый стандарт.

Вместо этого, упомянутая группа разработчиков выделила все API, которые используются в настоящее время наиболее популярными приложениями для Unix. Из тысяч существующих Unix-приложений они взяли 50 самых распространенных и выбрали 1179 функций API в качестве основы нового стандарта, который первоначально был назван SPEC1170. Позднее это название было заменено на «Единая Спецификация UNIX» (Single UNIX Specification), и данный стандарт становится теперь новой промышленной спецификацией Unix. Помимо указанных API в него входит часть интерфейсов POSIX. В состав спецификации продолжают включаться новые API.

Очевидная проблема во всей этой работе по определению API была лаконично сформулирована одним из сотрудников института NIST (National Institute of Standards and Technology Национального института стандартов и технологий США): «Самое милое в стандартах — это большой их выбор». В самом деле, множество противоречащих друг другу и быстро изменяющихся стандартов делает невозможным создание приложения, которое было бы переносимо на все платформы. Далее, в главе 11, мы рассмотрим язык программирования Java и предоставляемые им возможности по созданию переносимых приложений.

Более того, эти стандарты не являются полными, то есть во многих случаях приложениям приходится действовать «в обход» API. В результате приложение становится зависимым от аппаратуры и программного обеспечения нижних уровней: в тот момент, когда приложение обходит API, все проблемы, присущие процессоро-ори-ентированным архитектурам, возникают снова.

Машинная архитектура высокого уровня

Истинная независимость от аппаратуры может быть достигнута, если вместо определения отдельных API для разных специфических приложений (что имеет место в случае такой API-ориентированной архитектуры как Single Unix Specification), будет формально определен общий интерфейс для всех приложений. Более того, если в такой интерфейс заложены возможности расширения, то в любое время для достижения переносимости приложений к нему могут быть добавлены API Single UNIX Specification. Именно такой подход лежит в основе архитектуры AS/400, которая определяет законченный набор API для всех приложений и не позволяет последним обходить API.

Независимый от технологии машинный интерфейс (Technology-Independent Machine Interface), который часто называют просто MI[ 9 ], представляет собой формальное определение интерфейса для всех приложений и большинства компонентов операционной системы. Аппаратура, а также все программное обеспечение операционной системы, которому должны быть доступны подробности аппаратной реализации, располагаются ниже границы MI.

Чтобы понять, как достигается независимость программного обеспечения от изменений в аппаратуре, обусловленных технологическим прогрессом, необходимо кратко рассмотреть, как работает компилятор. Ранее было сказано, что в традиционной процессоро-ориентированной системе компилятор генерирует двоичный машинный код непосредственно из исходного текста, что иногда требует дополнительного шага ассемблирования. В AS/400 компилятор генерирует из исходного текста код MI, который оформляется в виде так называемого шаблона программы. На втором этапе транслятор AS/400 генерирует двоичный код по содержимому шаблона программы. Фактически, этот транслятор выполняет те же действия, что и заключительный проход современного компилятора. Затем, если явно не запрошено его удаление, шаблон программы сохраняется вместе с двоичным кодом в программном объекте. Такая программа называется отслеживаемой (observable). При переносе программного объекта на новую аппаратную базу, например, на 64-разрядный PowerPC, другой транслятор, созданный для новой аппаратуры, перетранслирует шаблон программы в новый двоичный код. Изменений в исходном коде при этом не требуется — чем и достигается независимость от технологии. Более подробное рассмотрение этого вопроса мы отложим до главы 4.

Значимость такой независимости очевидна для пользователей и ISV. Переход на 64-разрядную технологию RISC дает не только более мощный процессор — операционная система и все приложения сразу же становятся 64-разрядными. Для того чтобы воспользоваться преимуществами 64-разрядного оборудования не нужно ничего переписывать. В один день RISC-системы AS/400 получают 64-разрядную операционную систему и десятки тысяч 64-разрядных приложений.

Архитектура AS/400 заслужила титул «расширенной архитектуры приложений» (Advanced Application Architecture), так как предоставляет возможности, которых многие другие вычислительные системы все еще пытаются достичь с помощью API-ориентированного подхода. AS/400 уже сейчас независима от нижележащей технологии. Хотя независимость от аппаратуры важна, но не менее важна и независимость от деталей операционной системы. В AS/400 достигнуто и это. Термин «расширенная архитектура» подразумевает, что к ней могут быть добавлены вновь определяемые API других операционных систем, что обеспечивает еще большую переносимость приложений.

И это тоже есть!

«Это там есть; все там есть!», — восклицает телевизионная реклама известного соуса для спагетти. Вместо того, чтобы покупать ингредиенты и делать соус самому — убеждает голос за кадром — лучше просто купить бутылку этого соуса и быть уверенным, что все качественные и свежие составляющие, которые Вы использовали бы, уже там. Гленн Ван Беншотен (Glenn Van Benschoten), системный менеджер AS/400, любит использовать аналогию с соусом для спагетти для описания интегрированной сущности AS/400. Все, что Вы можете пожелать для своего компьютера, уже там есть.

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

Если бы Вы спросили разработчика из подразделения в Рочестере, в чем причина успеха AS/400, то вероятно получили бы ответ, что здесь знают, как создавать наилучшие коммерческие многопользовательские системы. Если «нажать» посильнее, Ваш собеседник, вероятно, начнет сравнивать конкретные возможности, такие как база данных или структура защиты, с возможностями других систем. На мой взгляд, главное не в этом. Да, у AS/400 мощная база данных и надежная система защиты, но этим обладают и другие системы. Отличительная черта AS/400, которую многие наши разработчики считают само собой разумеющейся, — то, что все компоненты спроектированы, чтобы работать вместе. Система AS/400 — это больше, чем просто сумма составных частей.

Если задать тот же вопрос ISV, то он, вероятно, скажет, что для AS/400 проще, чем для какой-либо другой платформы, разрабатывать и сопровождать приложения. ISV, имеющие свои приложения как для AS/400, так и для других платформ, например Unix, часто указывают на разницу в численности людей, работающих для одной или другой платформы. Обычно, для разработки приложений для AS/400 требуется гораздо меньше людей, и это также — заслуга интеграции. Гарантируя, что новая добавленная функция будет гладко работать со всеми остальными частями системы, мы сокращаем расходы на разработку для AS/400. Все системы, созданные в Рочес-тере до AS/400 включительно, решены интегрировано, и именно в этом секрет их успеха.

Но если даже наши собственные разработчики порой забывают об этом факторе, то благодаря чему AS/400 остается интегрированной системой? Ответ — MI. MI делает для обеспечения интеграции две вещи. Во-первых, он предоставляет общий интерфейс для всех приложений и функций операционной системы, реализованных поверх него, благодаря чему всем приходится использовать систему одинаковым образом. Во-вторых, MI — функционально законченный интерфейс. Так как обойти его невозможно, MI предоставляет все функции, которые могут потребоваться прикладной или системной программе. Если какая-либо нужная функция отсутствует, то программа не будет работать на AS/400. MI также обладает большими возможностями расширения, что позволяет включать в него новые функции по мере надобности.

Прежде чем кто-нибудь укажет на то, что другие системы Рочестера, такие как System/36, добивались интеграции без машинного интерфейса высокого уровня, я должен отметить, что MI обеспечивает и интеграцию, и аппаратную независимость. У System/36 был эквивалент машинного интерфейса для большинства системных функций, но не для приложений. В этой системе два отдельных процессора выполняли: один — пользовательские приложения, а другой — некоторые функции операционной системы. Доступ к этим функциям на втором процессоре был возможен только посредством строго определенного интерфейса между двумя процессорам. Данный интерфейс, подобно MI, гарантировал полноту набора функций и возможность их совместной работы. Приложения, однако, по-прежнему зависели от аппаратуры. По этой причине (как мы увидим в главе 3) для выполнения приложений System/36 на другой аппаратуре требовался эмулятор.

Отрицательная сторона интеграции — отсутствие гибкости. В интегрированных решениях обычно имеет место подход «все или ничего». Клиент не может выбрать

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

Трудно поверить в то, что в любой компьютерной системе есть компоненты, не предназначенные для тесной совместной работы, но часто именно так и обстоит дело. Такие компоненты как базы данных, подсистемы защиты и коммуникаций обычно разрабатываются независимо друг от друга и могут предназначаться для работы с разными ОС. В результате, такие компоненты обычно самодостаточны, то есть стремятся использовать минимальный набор возможностей, встроенных в ОС. Подобное разделение ведет к дублированию функций между ОС и отдельными компонентами. Оно также может привести к разным интерфейсам пользователя и системного оператора.

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

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

Глава 2

Технология PowerPC

«По сути своей, IBM s компания технологий», — сказал Лу Герстнер (Lou Gerstner) вскоре после того, как возглавил корпорацию в 1993 году. И действительно, чуть ли не все основные технологии компьютерной индустрии s от RISC до реляционных баз данных s вышли из IBM. В прошлом IBM не всегда удавалось коммерчески использовать свои изобретения, и Герстнер собирается это изменить. По его мнению, главное s продвижение нескольких ключевых технологий, одна из которых — RISC-микропроцессор PowerPC в AS/400 Advanced Series.

Микросхемы сжимаются на глазах

Статистика говорит, что сегодня в мире от 300 до 400 миллиардов микросхем, в том числе около 15 миллиардов кристаллов микропроцессоров. В основном, это микросхемы памяти. Произвести их в таком количестве за последние несколько лет позволил быстрый прогресс в технологии кремниевых микросхем. Подавляющее большинство микропроцессоров используются не в компьютерах, а в наручных часах, телевизорах, кухонных приборах и автомобилях. Например, в новом автомобиле обычно от 10 до 12 микропроцессоров, а в некоторых моделях sзначительно больше.

С каждым новым поколением микросхем производителям удается разместить на одном кристалле все больше транзисторов, примерно удваивая это число каждые 18 месяцев. Данная закономерность известна как закон Мура, названный так в честь Гордона Мура (Gordon Moore), председателя и одного из основателей Intel. В 1971 году Intel выпустила свой первый микропроцессор 4004, содержавший 2300 транзисторов на одной микросхеме. Современный кристалл микропроцессора содержит миллионы транзисторов. Предсказание Мура сбывается уже более четверти столетия1. Постоянное сокращение размера транзисторов позволяет увеличивать плотность их упаковки на кристалле. По мнению многих экспертов, вскоре после 2000 года появятся транзисторы размером всего лишь около 0,18 микрона; а еще менее чем через десять лет s 0,08 микрон. Для сравнения, толщина человеческого волоса примерно 80 микрон. Представьте себе тысячу транзисторов, размещенных на его срезе! Судя по такой стремительности прогресса, закон Мура продержится еще не один десяток лет. Не пройдет и десятилетия, и мы, вероятно, увидим микросхемы с более чем 100 миллионами транзисторов; а размещение на одной микросхеме миллиарда транзисторов может стать возможным уже лет через 15 лет. Все это обеспечит та же самая кремниевая технология, которая применяется для современных микросхем. Необходимость ее замены возникнет, по-видимому, не раньше чем через 20 лет. Однако у микросхем с высокой плотностью упаковки есть и минусы. Они невероятно сложны, и их разработка и производство становятся все дороже. В будущем экономические проблемы, вероятно, приведут к прекращению производства микросхем несколькими известными сегодня фирмами. Уже сейчас завод, производящий кристаллы для современных микросхем стоит более 2 миллиардов долларов, а стоимость производства микросхем с размером транзисторов менее 0,1 микрон, вероятно, «перевалит» за 10 миллиардов. С учетом продолжающегося падения цен на полупроводниковые микросхемы, можно предположить, что через 10 лет производителей микросхем останется не более десятка.

Никто не знает, кто выдержит эту гонку, и сегодняшние удачи ничего не гарантируют в будущем. Возьмем, например, Intel. Многие считают, что благодаря популярности ПК, Intel s крупнейший производитель микропроцессоров. Но это не так! Intel производит только около 1,5 процента всех микропроцессоров. Motorola, Hitachi и даже Zilog (помнит ли кто-нибудь Z80?) продают гораздо больше микропроцессоров, чем Intel. Своим успехом Intel обязан, главным образом, высоким ценам, которые он устанавливает на свои микросхемы для ПК. Другие производители продают микросхемы равной производительности дешевле. Но пока существуют ПК, Intel может запрашивать высокие цены.

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

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

Альянс PowerPC

В начале 1991 года Apple Computer подыскивала новый процессор для своих компьютеров. Ее специалисты полагали, что будущее процессоров ПК — в RISC-архитектуре. В то время процессоры ПК, производимые Motorola, Intel и другими фирмами, имели архитектуру CISC. Apple тогда использовала процессоры Motorola, и хотя последняя уже создала RISC-процессор, он не имел большого коммерческого успеха.

У технологии RISC фундаментальные преимущества над CISC. RISC-процессор более производителен, он упакован на кристалле меньшего размера и потребляет меньшую мощность. В Apple поняли, что вычислительная техника, в конце концов, будет двигаться в этом направлении, но в 1991 году подавляющее большинство доступных микропроцессоров по-прежнему имели архитектуру CISC.

В то время IBM производила одни из лучших RISC-процессоров. Они применялись в компьютерах RISC System/6000 (RS/6000). Все эти процессоры имели многокристальную 32-разрядную архитектуру, но IBM планировала выпустить в начале 1992 года однокристальную версию RCS (RISC Single Chip). Узнав, что Apple ищет новый RISC-микропроцессор, в IBM решили узнать, не подойдет ли им продукция IBM.

Оправившись от шока, вызванного тем, что их прямой конкурент на рынке ПК — IBM — пытается продать им процессоры, в Apple решили, что в этом что-то есть. Зная, что Motorola также работает над новым RISC-процессором, Apple предложила объединить усилия трех фирм. После переговоров IBM согласилась, и в сентябре 1991 года три фирмы официально объявили о совместной разработке некоторых новых технологий, включая большое семейство микропроцессоров. В основе дизайна микропроцессоров должен был лежать RSC. Новое семейство получило название PowerPC.

Три партнера понимали, что успех на рынке зависит от объема продаж новых микросхем и возможностей выбора программного обеспечения. Для этого они стали привлекать к использованию PowerPC производителей аппаратного и программного обеспечения, включая Toshiba, Canon, Zenith Data Systems, Harris Computer и Groupe Bull. Чтобы еще больше повысить объем продаж процессоров, члены альянса привлекли и фирмы, работающие вне области вычислительной техники. Хороший пример такого сотрудничества s компания Ford Motor. В будущих автомобилях Ford микропроцессоры PowerPC будут применяться для управления важнейшими узлами — от двигателя до системы торможения.

Эволюция PowerPC

Концепция RISC была разработана Джоном Коком (John Cocke) из IBM Research. Кок установил, что прогресс в области компиляторов достиг той точки, когда можно упростить набор команд процессора, и возложить на компилятор значительную часть работы, ранее выполнявшейся аппаратурой. Впервые идеи Кока были воплощены в миникомпьютере IBM 801. Процессоры PowerPC s прямые наследники 801.

Основным мотивом создания архитектур CISC было желание сократить семантический разрыв между двоичным машинным языком процессора и ЯВУ, используемыми программистами. В двоичный машинный язык вводились команды, соответствующие инструкциям языка высокого уровня. Идея заключалась в том, чтобы процессор исполнял меньшее количество сложных команд, что позволило бы сэкономить память. К несчастью, машинные команды стали настолько сложны, что при создании практически любого процессора приходилось применять микропрограммирование. Накладные расходы микропрограммируемого эмулятора замедляли выполнение часто встречающихся простых команд. Кок доказывал, что при использовании только простых команд, необходимость в микропрограммировании отпадет, а все команды будут выполняться аппаратурой непосредственно. Более того, если бы стоимость памяти не была столь существенна, то компиляторы могли бы напрямую подставлять код для выполнения более сложных функций. Потребности в памяти увеличились бы, но возросла бы и производительность.

Дизайн процессора 801 был заимствован у суперкомпьютеров s самых быстродействующих ЭВМ. Хотя сам термин «суперкомпьютер» до середины 70-х годов не использовался, но конструкторы, стремившиеся раздвинуть пределы возможностей аппаратных технологий, были всегда. Невозможно говорить о суперкомпьютерах, не вспомнив о Сеймуре Крее (Seymour Cray). Если хотите, Крей и суперкомпьютер — это синонимы. Современные архитектуры RISC-процессоров многим обязаны этому первопроходцу[ 10 ].

Значительно повысить производительность процессоров позволил метод конвейерной обработки (pipelining). На протяжении уже многих лет эта технология используется при создании всех компьютеров, от ПК до больших ЭВМ. Суть ее — в параллельном исполнении фрагментов последовательных команд на разных этапах аппаратного конвейера. Первый компьютер общего назначения, использовавший конвейерную обработку, появился еще в 1961 году. Это был IBM 7030, известный также под названием Stretch.

Рисунок 2.1а Конвейерный скалярный процессор — пятиэтапный конвейер команд.

Пример пятиэтапного конвейера команд показан на рисунке 2.1а. Время, необходимое для выполнения каждого этапа выполнения команды, называется временем цикла процессора (processor cycle time).

На рисунке 2.1б показана временная диаграмма пятиэтапного конвейера. В течение первого цикла процессора команда № 1 выбирается из буфера команд аппаратурой первого этапа конвейера. В течение второго цикла команда № 1 декодируется, и содержимое необходимых регистров считывается аппаратурой второго этапа. В то же самое время, аппаратура первого этапа считывает из буфера команд команду № 2. Теперь аппаратура разных стадий конвейера параллельно обрабатывает разные части двух разных команд. Благодаря такому параллелизму и достигается повышенная производительность процессоров с конвейерной обработкой. Обратите внимание: предполагается, что некоторая другая часть аппаратуры процессора обеспечивает заполнение буфера команд.

Рисунок 2.1b Пример временной диаграммы

В течение третьего процессорного цикла команда № 1 поступает на стадию выполнения и вычисления эффективного адреса (стадия 3), команда № 2 поступает на стадию 2, а команда № 3 s на стадию 1. Процесс продолжается вплоть до завершения пятого цикла процессора, когда выполнение команды: № 1 заканчивается и она покидает конвейер. Таким образом, выполнение каждой отдельной команды занимает полные пять циклов, но после того, как конвейер заполнен, на каждом цикле процессора завершается выполнение одной команды. Когда говорят, что для выполнения одной команды необходим один цикл процессора, подразумевается, что конвейер заполнен, что, понятно, близко к идеалу[ 11 ].

В начале 60-х годов Сеймур Крей в Control Data Corporation разрабатывал первый в мире суперкомпьютер — CDC 6600. Он планировал использовать конвейерную обработку и добивался, чтобы время выполнения всех команд было одинаковым. Ведь, как видно из приведенного примера, общее время выполнения команд определяется командой, имеющей самое большое время выполнения. Команды, выбирающие операнды из памяти или записывающие их в память, обычно выполняются дольше остальных. Если эти, работающие с памятью, команды выполняют также и логические или арифметические действия над данными, то время выполнения может стать очень большим.

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

Тогда это было очень непривычно: ведь большинство других компьютеров позволяли выполнять операции над данными в памяти без использования регистров. Например, команды S/360 позволяют сложить два находящихся в памяти операнда и записать сумму обратно в память. Эта операция занимает очень много времени, но выполняется одной машинной командой. Команды данного типа называются командами память-память.

Для выполнения той же самой операции на машине Крея потребовалось бы пять команд. Сначала две команды загрузки поместили бы данные в два регистра. Затем команда сложения просуммировала бы содержимое этих регистров и поместила бы результат обратно в регистр. И, наконец, команда сохранения переписала бы сумму из регистра в память[ 12 ]. Но если эффективно поместить все эти пять команд на конвейер и выполнять их параллельно, то общее необходимое для этого время будет меньше времени, необходимого для выполнения эквивалентной операции на машине с командами типа память-память. И все же большее число команд, требуемых для выполнения операции, было недостатком машины Крея.

В 1964 году появилась CDC 6600 s первая машина общего назначения с архитектурой загрузка/сохранение (load/store). Крей осознал связь между конвейерной обработкой и архитектурой набора команд, и это привело его к выводу о необходимости упрощения этой архитектуры для повышения эффективности конвейера. Современные RISC-процессоры используют подход Сеймура Крея — в них команды, работающие с памятью, выполняют только загрузку и сохранение. Вот почему RISC-машины быстрее CISC-машин с полным набором команд для работы с памятью. По той же причине и программы, скомпилированные для RISC, больше по размеру.

Вклад Сеймура Крея в разработку высокопроизводительных конвейеров не ограничивается только архитектурой набора команд. В CDC 6600 он применил аппаратуру, которая обеспечивала максимум производительности путем максимально возможной загрузки конвейера, то есть ситуацию, при которой на каждой его стадии выполняется часть некоторой команды. В реальности, между командами в программах существуют зависимости. Если команда на конвейере использует данные, которые сохраняются командой, идущей по конвейеру непосредственно впереди нее, то в определенный момент эти данные могут быть еще недоступны, что не только вызывает простой конвейера, но и останавливает выполнение всех последующих команд. Тем самым уменьшается производительность процессора.

В CDC 6600 было впервые реализовано оборудование, позволяющее процессору просматривать команды, расположенные далее в потоке команд, и определять, могут ли они быть запущены перед той, что ожидает сохранения результата. Идея аппаратного переупорядочивания команд на конвейере, известная как динамическое планирование (dynamic scheduling), служила поддержанию максимально возможной его загрузки и значительно повысила производительность CDC 6600.

В суперкомпьютерах 60-х была реализована и идея предсказания переходов. Команда перехода может разрушить конвейер. Вызванный ею простой затянется до тех пор, пока система не будет в состоянии решить, какая команда должна выполняться следующей. Идея предсказания переходов состоит в том, чтобы на основе опыта угадать, откуда следует выбирать команду, следующую после команды перехода. Использованное в IBM 360/91 сложное аппаратное обеспечение предсказания переходов позволило достичь отличных результатов.

360/91 обладала еще одной интересной аппаратной особенностью. Опираясь на ее опыт, Боб Томасуло (Bob Tomasulo), инженер IBM, усовершенствовал алгоритм Крея, созданный несколькими годами ранее, и создал новый алгоритм динамического планирования. Реализованный аппаратно, алгоритм Томасуло устранил многие случаи простоя конвейера путем выполнения команд не по порядку их следования. Команда, которая должна ожидать получения некоторого результата, более не останавливает команды, следующие за ней. Алгоритм Томасуло требовал невероятно сложной по тем временам аппаратуры, но на деле позволял достичь желаемого роста производительности.

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

В конце 60-х годов Джон Кок работал над проектом быстрого компьютера для научных расчетов в IBM Research Laboratory в Сан-Хосе (San Jose), штат Калифорния, и вплотную столкнулся со сложностью оборудования, необходимого для поддержания загрузки конвейера. Кок полагал, что если переложить большую часть ответственности за это на компиляторы, то оборудование значительно упростится и подешевеет. И тогда высокопроизводительная обработка перестанет быть прерогативой суперкомпьютеров. Так родилась идея RISC.

К сожалению, этот исследовательский проект был прерван прежде, чем Кок смог реализовать свои идеи. Еще один шанс сделать это представился ему в 1976 году, в исследовательской лаборатории IBM Yorktown в Нью-Йорке. Коку было поручено спроектировать и построить высокопроизводительный контроллер телекоммуникаций. Именно этот контроллер, получивший кодовое наименование 801 (по номеру здания, в котором работал Кок) обычно считается первым RISC-компьютером.

801 доказал, что планирование загрузки конвейерного процессора может быть возложено на компилятор. Сочетание компилятора, генерировавшего поток команд, оптимизированный для конкретного конвейерного процессора, и упрощенного процессора типа загрузка/сохранение, аналогичного машине Сеймура Крея, до сих пор остается непревзойденным.

Современные RISC-процессоры используют идею Джона Кока s оптимизирующий компилятор, соответствующий аппаратуре процессора. Их производительность обеспечивается технологическими достижениями как аппаратуры, так и компиляторов. Поскольку за последние несколько лет компиляторы очень быстро прогрессируют, то есть даже предложения переименовать RISC в «Relegate Interesting Stuff to Compilers»[ 13 ].

Первым продуктом IBM, в котором использовались идеи 801, был PC RT. Подразделению по созданию продукции для офисов в Остине понадобился новый процессор. В качестве отправной точки для разработки был взят 801. Новый микропроцессор, названный ROMP (Research/Office Products Microprocessor), включал в себя подмножество 801, что обеспечивало низкую себестоимость. Главным архитектором и менеджером разработки PC RT выступал Гленн Хенри. Ранее он был программным менеджером нашего проекта в Рочестере, а после выхода на рынок System/38 перебрался в Остин, где возглавил первый проект IBM по созданию RISC-компьютера.

801 использовался также и другими организациями в качестве базы для создания RISC-процессоров. В начале 80-х исследования по этой теме велись группой Дэвида Паттерсона (David Patterson) в Калифорнийском университете в Беркли (Berkeley) и группой Джона Хеннеси (John Hennessy) в Станфордском университете. Именно Паттерсон и придумал термин «RISC». Выпускники обоих упомянутых университетов работали в IBM Research и знали 801. Проект Паттерсона лег в основу микропроцессора SPARC, использовавшегося компанией SUN, а проект Хеннеси s микропроцессора MIPS. Тем временем, в расположенной по соседству компании HP разработкой архитектуры PA-RISC занимался Джоел Бирнбаум (Joel Birnbaum), ранее возглавлявший группу 801 в IBM Research. Таким образом, PA-RISC также s прямой потомок проекта 801.

Ранние процессоры RISC, как и 801, использовали один конвейер. Кок и другие сотрудники IBM полагали, что повысить производительность можно путем распределения на каждом цикле нескольких команд из обычного линейного потока по нескольким конвейерам. Такой компьютер был создан и назван суперскалярным. Первый суперскалярный RISC-процессор появился в 1990 году в RS/6000. В основе его архитектуры также лежал 801.

Чтобы отметить суперскалярное расширение RISC-процессора, IBM назвала эту архитектуру POWER (Performance Optimization With Enhanced RISC). Архитектура POWER стала стартовой площадкой объединенного проекта Apple, IBM и Motorola.

Рисунок 2.2. Эволюция PowerPC

Чтобы удовлетворить будущие потребности всех трех корпораций, архитектуру POWER требовалось несколько изменить. Большинство процессоров POWER были многокристальными. Некоторое упрощение архитектуры сделало возможным создание дешевых однокристальных вариантов (иначе говоря, микропроцессоров). Кроме того, архитектура POWER не поддерживала многопроцессорные системы, так что и здесь понадобились соответствующие добавления. Были также увеличены возможности поддержки предполагаемых будущих приложений. Наконец, 32-разрядная архитектура POWER была расширена путем включения 64-разрядных адресов и операций. В результате всех этих изменений на свет появилась новая архитектура s PowerPC. Ее эволюция, начиная с 801, показана на рисунке 2.2.

Усилиями инженеров Apple, IBM и Motorola был создан новый проектный центр для разработки микропроцессоров PowerPC. Персонал Somerset[ 14 ] Design Center, расположенного в Остине, состоит, в основном, из инженеров IBM и Motorola. В конце 1995 года Somerset стал частью подразделения IBM Microelectronics. Сотрудничающие фирмы имеют право производить и продавать процессоры, разработанные в Сомерсете. Например, Apple покупает микросхемы PowerPC как у IBM, так и у Motorola. Процессоры PowerPC Motorola производятся на заводе этой фирмы в Остине. IBM производит свои микросхемы PowerPC в Барлингтоне (Burlington), штат Вермонт.

Важно отметить, что RISC-процессоры в последние несколько лет неуклонно прогрессируют. Практически каждый их производитель, включая консорциум PowerPC, ныне поставляет на рынок 64-разрядный RISC-процессор, на кристалле которого установлена аппаратура динамического планирования, использующая описанный выше алгоритм Томасуло, а также предсказания переходов. Удивительно, но мы, кажется, совершили полный круг? В современные процессоры снова включена вся аппаратура, для устранения которой и была первоначально предложена RISC-архитектура. Сеймур Крей мог бы гордиться: ведь аппаратные решения, предложенные им впервые в 1964 году, взяли верх над более простыми архитектурами ранних RISC-процессоров. Это определенно не те RISC-процессоры, что раньше!

RISC-процессор AS/400 для коммерческих расчетов

В 1990 году была разработана новая архитектура RISC-процессора для будущих моделей AS/400. Первоначальная архитектура процессора, получившая неуклюжее название Internal Microprogrammed Interface (IMPI)[ 15 ] была разработана в середине 70-х для System/38 и предназначалась для поддержки интерактивных коммерческих систем обработки транзакций.

IMPI была преимущественно архитектурой память-память. С помощью одной команды данные могли быть выбраны из памяти, изменены процессором и записаны обратно. Обычно, интерактивные приложения обработки транзакций перемещают много данных, но изменяют лишь их малую часть. Рассмотрим типичную операцию обновления инвентарной описи.

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

Описанная операция может считаться отдельной транзакцией, или быть частью более крупной транзакции. В любом случае, мы имеем дело с обработкой транзакций.

Кроме того, данное приложение интерактивно, так как им управляет человек за терминалом (приемщик заказа). Этому человеку исключительно важно получить ответ быстро. Следовательно, для создания интерактивной системы обработки транзакций абсолютно необходим процессор, который в состоянии перемещать большие объемы данных и выполнять операции в короткое время. AS/400 отлично подходит для приложений такого типа.

На протяжении многих лет мы исследовали тысячи коммерческих приложений, написанных для AS/400 и других многопользовательских систем Рочестера. Все они имеют ряд общих характеристик. Рассмотрим некоторые из них.

Возможность поддерживать параллельную работу сотен и даже тысяч пользователей.

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

Адресация структур данных в AS/400 выполняется посредством указателей, что требует использования целочисленной арифметики для обновления адресов.

При обработке данных используются, в основном, строковые или целочисленные сравнения, обновления и вставки. Арифметика с плавающей точкой используется редко.

Циклы в приложениях для AS/400 встречаются реже, а нециклические переходы чаще, чем в приложениях для научных расчетов.

Обрабатываемые данные разбросаны по большому объему дискового пространства. Объем данных, выбираемых за одно обращение к диску, относительно невелик, а последовательные обращения с большой вероятностью будут обращены к разным дискам.

Сравним приложение данного типа с типичным приложением для инженерных или научных расчетов, выполняемом на специализированной рабочей станции. Последние часто называют вычислительными (compute-intensive), так как они выполняют большие объемы вычислений с относительно малыми объемами данных. Обычно, такие приложения имеют малые рабочие наборы команд с большим числом компактных циклов вычислений с плавающей точкой. Ввод-вывод в них чаще последовательный, а не прямой. Сеймур Крей показал, что для приложений такого типа наилучшим будет процессор, который обрабатывает данные только в регистрах, как RISC-процессоры.

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

С момента своего появления архитектура IMPI неоднократно расширялась и модифицировалась. Но даже и с учетом этих изменений ее нельзя признать подходящей для выполнения большого объема вычислений. Большинству специалистов в

Рочестере было ясно, что для удовлетворения будущих потребностей в вычислительной мощности необходимо введение характеристик RISC-процессора.

Итак, в 1990 году мы начали проект по добавлению к IMPI свойств RISC. Сначала мы хотели использовать процессор от RS/6000, но быстро отказались от этой мысли. Архитектура POWER была разработана для технических расчетов. Ей недоставало ряда характеристик, необходимых для выполнения коммерческих вычислений. Кроме того, она не могла обрабатывать большие объемы данных с требуемой эффективностью.

В то время RISC-процессоры были, как правило, 32-разрядными (то есть ширина трактов данных и регистров процессора равна всего лишь 32 битам). Большинство имело и 64-разрядные регистры с плавающей точкой, но целочисленные регистры — те, которые используются для коммерческих расчетов, — имели только 32 разряда. А так как RISC-процессор перед обработкой данных должен сначала загрузить их в свои регистры, то при больших объемах данных 32-разрядная ширина быстро становится недостатком. Архитектуры CISC, такие как IMPI, могут выполнять команды память-память, обрабатывая данные без загрузки их в регистры, таким образом, это узкое место здесь фактически обходится.

Приняв во внимание эти соображения, мы решили, что для нашего будущего компьютера необходим полностью 64-разрядный процессор. Дополнительно на нас влияло то, что ширина адреса в AS/400 равна 48 битам, и этот адрес невозможно втиснуть в 32-разрядный регистр. 64-разрядный процессор позволял нам расширить адрес, используемый в IMPI, с 48 до 64 бит. Наши расчеты показывали, что в будущем, по мере того как системы AS/400 будут становиться все больше и больше, настанет момент, когда потребуется больший размер адреса.

Нельзя было не брать во внимание и объем микрокода, который пришлось бы изменить. Начав с IMPI, мы смогли бы минимизировать эти изменения.

Итак, было принято решение: взять IMPI, расширить его до 64 бит и добавить вычислительные операции, присущие RISC. Нам предстояло создать первый гибридный процессор CISC/RISC, предназначенный исключительно для коммерческих вычислений. Мы назвали его C-RISC — «Commercial-RISC».

Технология PowerPC для AS/400

Президентом IBM в 1991 году был Джек Кюлер (Jack Kuehler). Он привел IBM к соглашению с Apple и Motorola о создании микропроцессоров PowerPC. Джек Кюлер считал, что к концу десятилетия все компьютеры, от самых маленьких, умещающихся на ладони, до суперЭВМ будут использовать RISC-процессоры. Он также полагал, что компании, создающие такие микропроцессоры, можно будет пересчитать по пальцам одной руки, и был твердо уверен, что альянс PowerPC станет одной из таких выживших фирм.

Кюлер не мог понять, почему обе его основные лаборатории одновременно занимаются разработкой новых RISC-процессоров. Лаборатория в Остине ра ботала над спецификацией PowerPC, а лаборатория в Рочестере s над C-RISC. I Кюлер был убежден в необходимости объединить усилия двух этих исследовательских центров, а также в том, что PowerPC подойдет и тем, и другим. Он стал выяснять, почему Рочестер не может использовать этот процессор. Мы покорно ездили в Армонк (Armonk), штат Нью-Йорк, где попытались объяснить различия между процессорами для коммерческих и научных расчетов. Кюлер не оспаривал успехи Рочестера, но и не принимал наши доводы. Он требовал дополнительные данные в обоснование нашей позиции. «Неужели RS/6000 не может выполнять и коммерческие вычисления?» — спрашивал он. Наконец, примерно после третьего визита в Армонк нам удалось его убедить.

Специалисты Рочестера знали, о чем говорят. Они понимали как делать процессоры для коммерческих вычислений, и чем эти процессоры отличались от предназначенных для технических расчетов. И все же Кюлер настоял, чтобы через 90 дней мы вернулись к нему с ответами на два вопроса: «Как изменить архитектуру PowerPC, чтобы она стала подошла для AS/400?» и «Сколько будет стоить перевод AS/400 на эту новую архитектуру?». Тем самым Кюлер дал нам возможность влиять на проект PowerPC. Он также изъявил желание финансировать любые дополнительные расходы, связанные с переходом на новый процессор.

В начале апреля 1991 года я возглавил группу из 10 человек, которая должна была дать ответ на оба эти вопроса. Кюлер также дал указание главе IBM Research, отвечавшему за согласование архитектуры PowerPC с Apple и Motorola, работать в тесном контакте с нами. Кроме того, наши инженеры тесно сотрудничали со своими коллегами из Остина.

Успех проекта во многом зависел от из рочестерской команды:, чьи инженеры были в числе самых лучших. Задача была не из легких. Сначала казалось, что требования AS/400 прямо противоположны задачам PowerPC. Затем возникло ощущение, что в результате слияния этих двух архитектур Рочестер лишится возможности создавать процессоры, оптимизированные для коммерческих расчетов. Нечего и говорить, как горячи были споры!

Было решено начать с архитектуры PowerPC в том виде, как она была определена на тот момент. К ней следовало добавить расширения, необходимые для AS/400. В результате должно было получиться нечто новое, заранее названное, в отличие от базовой архитектуры PowerPC, Amazon.

Хотя в Рочестере и были определенные сомнения в плодотворности идеи общей архитектуры RISC, тем не менее, ее разработка шла быстро. Основная роль здесь принадлежала Энди Уоттренгу (Andy Wottreng) и Майку Кор-ригану (Mike Corrigan). Они выполнили выдающуюся работу по интеграции технических требований AS/400 в новую архитектуру. В результате, впервые была создана архитектура RISC, которая одинаково хорошо подходила и для коммерческих, и для технических приложений.

За координацию проекта отвечал Дэррил Соли (Darryl Solie). Он находился в тесном контакте с обеими группами разработчиков в Остине и Рочесте-ре и обеспечивал взаимодействие между ними. Проектировщики Рочестера многому научились у инженеров других подразделений IBM и Motorola. Уровни производительности процессоров, которые сперва казались недостижимыми, внезапно становились возможными. В результате, сейчас в Рочес-тере создаются одни из самых быстрых процессоров в мире. Наша лаборатория отвечает внутри IBM за разработку новых 64-разрядных процессоров для коммерческих вычислений.

Всякий раз, когда возникали трения, разгорались споры, и кто-нибудь начинал утверждать, что порочна идея в целом, в дело вмешивался Билл Берг (Bill Berg). Спокойно, дипломатично и быстро убеждал нас в том, что мы s на правильном пути, и что только мы можем пройти его до конца. Позднее Билл способствовал тому, чтобы убедить разработчиков использовать при создании программного обеспечения новой операционной системы объектно-ориентированные технологии.

Архитектура PowerPC должна была работать как в 32-разрядном, так и в 64-разрядном режимах. Все 64-разрядные версии PowerPC должны были иметь и 32-разрядное подмножество. Мы сосредоточились только на 64-разрядном режиме, практически не изменив 32-разрядное подмножество.

По мере разработки новой архитектуры мы могли предварительно оценить ее стоимость. Работа велась напряженно и была завершена за 90 дней, но результаты не слишком впечатляли.

Многие из необходимых нам архитектурных изменений было бы трудно внести в ранние версии процессоров PowerPC, разработанные в Сомерсете. Процессоры поздних моделей AS/400 должны были обрабатывать очень большие объемы данных, и для нужной производительности требовались очень широкие шины данных. Мы даже не пытались ничего добавлять в конструкции процессоров PowerPC 601, 603 или 604, так как они поддерживали только 32-разрядный режим. Было также крайне сомнительно, сможем ли мы усовершенствовать первый разработанный в Сомерсете 64-разрядный процессор (его окончательное название s 620), так как плотность упаковки элементов на этом кристалле была недостаточна для того, чтобы сделать его подходящим для наших моделей — пришлось бы разработать многокристальную версию архитектуры.

Даже в отношении младших моделей AS/400 у нас не было полной ясности. Некоторое время мы предполагали применить усовершенствованный вариант 620, который мы назвали 621, но в конце концов решили, что проще всего разрабатывать процессоры для AS/400 внутри IBM.

Одновременно с нами разработчики RS/6000 также пришли к заключению, что не смогут использовать ранние версии процессоров PowerPC в своих старших моделях. Для младших моделей подходил однокристальный процессор разработанный в Сомерсете, но для более высокопроизводительных моделей требовался многокристальный процессор. Кроме того, наши коллеги хотели включить в свой проект некоторые коммерчески выгодные возможности технических вычислений, а именно, NIC (numerically intensive computing), большинство из которых отсутствуют в обычном PowerPC. Также было добавлено больше конвейеров и новые вычислительные команды. Созданное в результате расширение первоначальной архитектуры POWER получило название POWER2.

Впервые процессоры архитектуры POWER2 были применены в RS/6000 в 1993 году. Они также использовались в RS/6000 Scalable POWERparallel System (RS/6000 SP). Последняя система ознаменовала выход IBM на рынок компьютеров параллельных вычислений. В RS/6000 SP может работать параллельно много таких процессоров. Параллельные машины очень хороши для ряда научно-технических и некоторых коммерческих приложений, например, для просмотра больших баз данных.

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

У первого общего процессора PowerPC, предназначенного как для AS/400, так и для RS/6000, было несколько названий. Разработчики RS/6000 часто называли его POWER3, или PowerPC 630. Мы дали ему внутреннее имя Belatrix. Беллатрикс s это звезда в созвездии Ориона. Немногие знают, что ее называют также звездой Амазонки (Amazon Star). Belatrix должен был стать звездой архитектуры Amazon.

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

Рочестер должен был сделать первые процессоры PowerPC применимыми для коммерческих задач. Первоначально они предназначались исключительно для AS/400.

Позже было принято решение: начиная с 1997 года использовать новое поколение 64-разрядных процессоров PowerPC, разработанных в Рочестере, и для RS/6000.

После прекращения работ над Belatrix в Остине начали разработку новой версии 630 — 64-разрядного процессора PowerPC, который должен был обеспечить вычислительную производительность, необходимую для будущих систем. Мы в Рочестере также стали разрабатывать свою версию Belatrix, которая предназначалась для серии AS/400 1998 года. Так как Belatrix назван по имени звезды, а Миннесота известна как штат Серверной звезды (North Star), то мы назвали новый процессор Northstar[ 16 ].

В области программного обеспечения ситуация с PowerPC была гораздо хуже, по сравнению с тем, что мы обещали Кюлеру. Все прикладное и системное программное обеспечение, работавшее поверх MI, было защищено благодаря независимой от технологии архитектуре AS/400. Однако, поскольку PowerPC сильно отличается от IMPI, то микрокод, расположенный ниже MI, было необходимо переделать под новый процессор. Это нелегкая задача, несмотря на то, что часть ее можно было осуществить с помощью автоматизированных средств. Между тем наши программисты должны были заниматься выпуском новых версий AS/400. Мы подсчитали, что для работы с RISC-процессором потребуется нанять несколько сотен новых системных программистов.

Наконец, мы были ограничены по времени. Первоначально планировалось выпустить новые процессоры C-RISC в середине 1994 года, мы уже мечтали о них для Advanced Series. При использовании PowerPC нам пришлось бы изменить планы и передвинуть выпуск RISC-процессоров на 1995 год s именно столько времени потребовалось бы для разработки нужных расширений и переписывания внутреннего кода. Пришлось бы оснащать Advanced Series процессорами IMPI и обеспечить возможность их модернизации процессорами PowerPC, когда последние будут готовы.

В начале июля 1991 года мы вновь нанесли визит Джеку Кюлеру. Большинство из нас полагали, что он поблагодарит за проделанную работу, сделает вывод, что переход на процессор PowerPC будет слишком дорогим и отправит обратно заниматься созданием C-RISC. Но Кюлер ничего такого не сделал. Вместо этого он попросил нас ускорить работу и предоставил необходимые для этого ресурсы. Так, внезапно для нас, пришлось полностью изменить направление работ над Advanced Series как в области аппаратного, так и программного обеспечения.

В конце июля мы завершили реорганизацию лаборатории для работы над новой системой. Ответственность за разработку новой модели процессора, названной Muskie, была возложена на Рочестер. Этот многокристальный процессор был предназначен для коммерческих вычислений на очень больших компьютерах. Разработка младших моделей серии AS/400 была переведена в лабораторию IBM в Эндикот-те. Эта линия получила наименование Cobra, и ее процессоры должны были быть однокристальными и полностью 64-разрядными.

Как уже упоминалось, первоначально мы планировали только 64-разрядный режим процессора. В конце концов, AS/400 не использует 32-разрядный режим, да и никто более не собирался использовать ранние 32-разрядные процессоры, так что реализовывать эту архитектуру в полном объеме, как нам казалось, не имело смысла. Но примерно через год, когда стало ясно, что AS/400 необходимо поддерживать все прикладное программное обеспечение, написанное для процессоров PowerPC, это решение было изменено. Поскольку большая часть таких программ написана для 32-разрядных процессоров, то и нам пришлось включить во все свои процессоры 32-разрядное подмножество. Это также должно было обеспечить возможность использовать наши новые PowerPC на других системах IBM.

Одновременно активизировалась работа по переносу микрокода AS/400 на новые процессоры. Это была возможность ревизии внутренностей операционной системы AS/400, чего не делалось с момента разработки System/38. Поскольку мы собирались перекраивать самые основы, то было решено идти до конца и использовать новейшие объектно-ориентированные методологии программирования. Мы планировали получить самую современную операционную систему.

За организацию работ по переделке основ операционной системы отвечал Майк Томашек (Mike Tomashek). Майк знал, что у него нет ни людей, ни W опыта для того, чтобы уложиться в отведенные сроки. Любой здравомыслящий человек подтвердил бы, что это невозможно. Вместе с ключевыми раз-1 работчиками, такими как Билл Берг и Крис Джонс (Chris Jones) Майк разработал план. Им было нужно нанять сотни новых людей, обучить их объектно-ориентированным технологиям и переписать важнейшие части операционной системы AS/400 за короткие сроки. Майк не потратил много времени на раздумья и дебаты. Он просто объявил, что план сработает, и на полной скорости двинулся вперед.

В конце 1991 мы начали массовый найм программистов. В ряде крупнейших газет Америки стали появляться объявления о том, что в Рочестере требуются системные программисты с опытом работы на С++. Нам удалось быстро нанять несколько сотен новых программистов. Тогда многие обозреватели удивлялись, для чего нам это понадобилось, но теперь они знают.

Прежде чем перейти к более подробному рассмотрению архитектуры PowerPC, хочу напомнить о нашей «перечной» системе рейтинга. Оставшаяся часть этой главы — лишь для тех, кому нужны дополнительные подробности. Обратите внимание, что когда мы начнем обсуждение реализации процессора, материал станет еще «острее». Если «попробовав этой информации Вы найдете ее «чересчур», просто пролистайте книгу, пока не дойдете до тех разделов, где меньше специй.

Архитектура PowerPC

Архитектура PowerPC обладает всеми обычными характеристиками архитектуры RISC: команды фиксированной длины, операции регистр-регистр, простые режимы адресации и большой набор регистров. Но есть и характеристики, отличающие ее от

других.

Как уже упоминалось, архитектура PowerPC — полностью 64-разрядная с 32-разрядным подмножеством. Она допускает как 32-разрядные, так и 64-разрядные версии процессоров PowerPC, но все они должны поддерживать, как минимум, 32-разрядное подмножество. Архитектура определяет переключатель режима 32/64, которые может использоваться операционной системой, чтобы позволить 64-разрядному процессору выполнять 32-разрядные программы.

В основе набора команд лежит идея суперскалярной реализации. В суперскалярном процессоре за один такт несколько команд могут быть распределены на несколько конвейеров. Аппаратура процессора просматривает поток команд и отправляет на выполнение максимально возможное число независимых команд (обычно от двух до четырех за цикл). Эти команды могут далее выполняться параллельно и даже завершиться в порядке, отличном от первоначального. Такой дополнительный параллелизм может значительно увеличить общую производительность процессора.

Команды направляются одновременно в три независимых исполняющих блока. Общая структура PowerPC показана на рисунке 2.3: блок переходов, блок фиксированной точки и блок плавающей точки. Также показан кэш команд[ 17 ], кэш данных, память и пространство ввода-вывода, которое в данной архитектуре выглядит как часть памяти.

Рисунок 2-3 Модель архитектуры PowerPC

Для каждого исполняющего блока архитектурой определен независимый набор регистров. Любая определенная архитектурой команда может выполняться только одним типом управляющих блоков. Таким образом, у каждого блока собственный набор регистров и собственный набор команд. Эти исполняющие блоки часто называют процессорами, так как им присущи все характеристики процессора. Можно считать, что процессор PowerPC содержит три отдельных процессора s исполняющих блока. При этом каждый исполняющий блок может иметь несколько конвейеров команд. Если, например, для модели, оптимизированной для вычислительных задач, важна производительность операций с плавающей точкой, то блок плавающей точки может содержать два и более конвейеров и, таким образом, выполнять более одной команды плавающей точки одновременно. То же самое верно и для двух других блоков. В принципе, возможно создать процессоры PowerPC, способные выполнять пять и более команд одновременно.

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

Другая характеристика архитектуры PowerPC, отличающая ее от обычного RISC-процессора s использование нескольких составных команд. Самой большой недостаток RISC по сравнению с CISC — увеличение объема кода. Для выполнения одной и той же программы RISC требуется больше команд, чем CISC. Составные команды позволяют уменьшить это разрастание кода. Некоторые из них очень просты, например, обновление регистра базы при загрузке и сохранении, что позволяет исключить дополнительную команду прибавления. Другие более сложны, например, команды множественной загрузки и сохранения, позволяющие перемещать значения нескольких регистров одной командой. Есть также команды загрузки/сохранения цепочек, которые позволяют загружать и сохранять произвольно выровненную цепочку байтов. Фанатики CISC узнают в последней паре команд не слишком хорошо замаскированные команды пересылки символов.

Ортодоксы RISC негодуют и обвиняют архитекторов PowerPC в том, что они «продались» сторонникам CISC. На самом же деле, надо просто понять, что в реальности некоторые операции, такие как пересылка невыравненных строк байтов, происходят достаточно часто и требуют определенной оптимизации. Если составная команда дает то, что нужно, даже нарушая при этом какое-то неписаное правило «чистого» RISC, то пусть так и будет. Составные команды не означают возврата к архитектуре CISC, однако их применение в RISC-процессорах лишний раз доказывает, что в мире нет ничего абсолютно белого или черного.

Интенсивное применение суперскалярных возможностей и использование составных команд составляют философию проектирования архитектуры PowerPC. Эта философия используется также и другими архитектурами, такими как Sun SuperSPARC и Motorola 88110. Есть мнение, что такая сложность затрудняет достижение процессорами высоких тактовых частот, обычно измеряемых мегагерцами (МГц). Сторонники этой точки зрения полагают, что большая производительность может быть достигнута скорее за счет высокой тактовой частоты, а не интенсивного параллелизма на уровне команд.

Что такое МГц? В последние годы стало популярным выражать производительность микросхемы процессора ЭВМ с помощью этой единицы измерения. Для простоты восприятия, ее можно соотнести с оборотами в минуту автомобильного двигателя: эта величина показывает, насколько быстро вращается двигатель автомобиля, или сколько оборотов в минуту совершает коленчатый вал. Скорость процессора можно рассматривать как число тактов, которое он может выполнить в секунду. За один такт процессор обычно может выполнить одну простую команду, так что иногда данная величина воспринимается как приблизительное число команд, выполняемое процессором в секунду. Физическая единица герц (Гц) получила свое название в честь немецкого физика и равна одному циклу в секунду. Один мегагерц (Mrii)s это миллион циклов в секунду.

Философию высокой тактовой частоты можно проиллюстрировать и примерами архитектур Digital Alpha, HP PA-RISC и MIPS R4000. Возьмем, например, PA-RISC 1.1. Этот процессор обычно выполняет две команды за такт. Менее мощные модели PowerPC могут за такт исполнять три команды, тогда как старшие модели s четыре и более. Этот дополнительный параллелизм дает PowerPC выигрыш в производительности, хотя и за счет увеличения сложности, что может снизить тактовую частоту.

Спор о том, какая из этих двух точек зрения лучше, продолжается. Противоборствующие лагеря условно можно назвать «Speed Daemons» (высокая тактовая частота) и «Brainiacs» (сложность). Суть вопроса в том, что тактовая частота, измеряемая мегагерцами, не всегда адекватно отражает общую производительность процессора. 150 МГц Brainiac может легко превзойти по производительности 300 МГц Speed Daemon. Все зависит от выполняемой программы и степени параллелизма команд, которой может достичь компилятор.

Некоторые новости указывают на то, что чаша весов склоняется на сторону архитектур Brainiac, таких как PowerPC. Судя по описанию, новая архитектура HP, получившая название PA-RISC 2.0, выглядит так, словно ее создатели поддались зову сирены сложности. Так как архитектура PA-RISC 2.0 остается процессор- ориентированной, то как объявлено HP, 64-разрядные приложения для новой аппаратуры появятся примерно через 3-5 лет.

Расширения архитектуры PowerPC

Так как первое поколение процессоров PowerPC создавалось специально под AS/400 и не было PowerPC в полном смысле, мы решили дать этим процессорам новое название s PowerPC Optimized for the AS/400 Advanced Series, но так как это труднопроизносимо, решено было остановиться на более кратком варианте s PowerPC AS. Большинство расшифровывают AS как Advanced Series, но многие из нас предпочитают считать, что это Amazon Series. Во втором поколении наших процессоров, представленном в 1997 году, мы реализовали и полную архитектуру PowerPC, и все расширения. Так как те же самые процессоры используются RS/6000, то обозначение AS более не имеет смысла. Самое существенное новшество архитектуры для AS/400 — использование тегов памяти (memory tags), которые будут подробно рассмотрены в главе 8. А вкратце мы поговорим об этом прямо сейчас.

В System/38 была реализована концепция одноуровневой памяти. Проще говоря, вся память, включая дисковую, представляет собой большое единое адресное пространство. Нам был необходим эффективный механизм защиты памяти от пользователей, не имеющих права доступа к ним. В MI адресация выполнялась с помощью 16-байтовых указателей. Указатель содержит некоторый адрес, и пользователь может этот адрес изменить (подробнее об этом будет рассказано в главе 5). Поскольку адрес после изменения может указывать на любую область памяти, необходимо предотвратить неавторизованные изменения адресов пользователями.

С каждым словом памяти System/38, имеющим 32 разряда данных, связан специальный бит защиты памяти, называемый битом тега (tag bit). Указатель MI занимает четыре таких слова. Всякий раз, когда операционная система сохраняет в четырех последовательных словах памяти указатель, аппаратура включает (устанавливает в 1) четыре бита тега, для индикации того, что указатель содержит адрес, допустимый для данного пользователя. Если пользователь изменяет в памяти любую часть указателя, то аппаратура выключает (устанавливает в 0) бит тега. Если хотя бы один из битов тега сброшен, то адрес в указателе неверен и не может быть использован для доступа к памяти.

В целях безопасности бит тега не может быть одним из битов данных внутри слова, так как последние пользователь может видеть и изменять. Он должен быть скрытым, то есть храниться в недоступной пользователю области памяти, но где именно?

System/38 использует для каждого слова памяти биты кода коррекции ошибок. Содержащая их часть памяти невидима программам, работающим поверх MI. Мы решили добавить к битам кода коррекции ошибок еще один и использовать его как бит тега. При изменении слова памяти какой-либо пользовательской программой, процессор должен автоматически сбрасывать скрытый бит тега. Ведь если данное слово станет частью указателя, то тот будет неверным. Только микрокод расположенный ниже MI имеет команды для включения битов тега.

В памяти AS/400 также используются биты тега. Поскольку в архитектуре PowerPC таковые не предусмотрены, нам пришлось добавить к ней режим активных тегов (tags-active mode). В этом режиме процессор «знает» о битах тега и будет сбрасывать их всякий раз, когда пользователь изменяет слово в памяти. Все процессоры AS/400 работают в режиме активных тегов. Существующие процессоры PowerPC используют режим неактивных тегов.

65-разрядный процессор?

В AS/400 ширина слова памяти возросла до 64 разрядов данных. С каждой восьмеркой байтов памяти AS/400 связан бит тега и указатель MI, занимающий два таких слова. В 1991 году нам виделись некоторые преимущества в том, чтобы хранить два теговых бита в регистрах новых RISC-процессоров, так же как и в памяти. Кроме того, мы хотели сократить размер указателей MI до 8 байтов. Внутри 16-байтовых указателей было неиспользуемое пространство, и казалось, что как раз настал подходящий момент сжать их.

Для того чтобы хранить такие тегированные указатели в регистрах, размер целочисленных регистров нужно было увеличить до 65 разрядов. Мы разрабатывали описанную схему около года, но в 1992 году отказались от нее и вернулись к решению, хранить теги только в памяти. На то было три основных причины. Во-первых, изменение размера указателя влияло на OS/400 и требовало слишком многих модификаций ее кода. Во-вторых, такой подход ограничивал будущие расширения размера адреса 64 разрядами. И третье, самое важное — процессоры в режиме активных тегов оказались бы несовместимы с набором команд PowerPC.

Первоначально мы не считали совместимость с PowerPC важной. Будущие процессоры, реализующие режим неактивных тегов, где 65-й разряд игнорируется, были бы полностью совместимы с PowerPC. А реализация 32-разрядных команд в режиме активных тегов и соответствующее программное обеспечение не планировалась даже в начале проекта. Ведь предполагалось, что этот режим будет использоваться только операционной системой AS/400, которая имеет дело с 64-разрядными командами.

Затем, когда было решено поддерживать совместимость с набором команд PowerPC, мы избавились от 65-го разряда в процессоре. Тогда намечалось некое слияние операционных систем IBM (см. Приложение). В рамках этого проекта предполагалось и программное обеспечение, большая часть которого предназначалась для 32-разрядного процессора. Поэтому мы обеспечили поддержку 32-разрядного набора команд всеми процессорами даже в режиме активных тегов. Наши процессоры второго поколения имеют режимы как активных, так и неактивных тегов и могут исполнять все прикладное и системное ПО PowerPC.

Хотя мы вернулись к 64-разрядным процессорам уже много лет назад, даже в IBM есть люди, по-прежнему упоминающие 65-разрядные, которые так никогда и не были созданы. Эта путаница возникает потому, что многие не знают, что собственно делает бит тега. Вероятно, если бы мы назвали его «битом защиты указателя в памяти» (pointer in memory protection), то не ввели бы в заблуждение столько народу. Но боюсь, тогда бы нам пришлось все время объяснять, зачем нам понадобился «бит pimp»[ 18 ].

Система команд Amazon

Архитектура PowerPC определяет привилегированные операции и команды, используемые только операционной системой и не предназначенные для прикладных программ. В AS/400 после специальных расширений этим «ведает» режим активных тегов. Например, механизм трансляции адреса должен поддерживать и одноуровневую память с единым адресным пространством, и обычную память с отдельным адресным пространством для каждого процесса. Мы используем режим активных тегов для того, чтобы приказать процессору использовать одноуровневую память. В режиме неактивных тегов процессор использует обычную трансляцию адреса PowerPC.

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

А сейчас хочу привести некоторые цифры. Они помогут подытожить разговор об изменениях в архитектуре AS/400 и связанных с ними перспективах развития архитектуры PowerPC.

32-разрядная архитектура PowerPC определяет 187 команд, причем 11 из них — необязательные.

64-разрядная архитектура PowerPC определяет 228 команд (187 из 32-разрядного набора + 41 дополнительная), из них 21 — необязательная.

Архитектура Amazon определяет 253 команды (228 из 64-разрядного набора PowerPC + 25 дополнительных), из них 20 — необязательные. Заметьте, что 25 дополнительных команд доступны только в режиме активных тегов. Режим неактивных тегов поддерживает лишь 64-разрядный набор команд PowerPC. Но учтите, что определение любой архитектуры динамично и конкретные числа могут изменяться!

Реализации процессора AS/400

Первые использовавшиеся в AS/400 RISC-процессоры поддерживали только режим активных тегов и только структуру ввода-вывода AS/400. Поэтому они выполняли приложения, но не операционные системы, написанные для стандартного процессора PowerPC. Любая другая операционная система на одном из этих процессоров для таких функций как ввод-вывод должна пользоваться средствами, предоставляемыми операционной системой AS/400. (Подробнее об этом — в следующих главах).

Последнее поколение RISC-процессоров для AS/400е поддерживает и режим активных тегов, и режим неактивных тегов, а, кроме того, обе структуры ввода-вывода одновременно. Они способны исполнять любую ОС для PowerPC и используются как в серии AS/400е, так и в RS/6000. Процессоры будущего сохранят эти характеристики.

Процессоры Muskie первого поколения

Процессор первого поколения, известный под названием Muskie[ 19 ], был разработан в Рочестере в 1995 году как старшая модель процессора для AS/400. На тот момент он был самым быстрым процессором PowerPC и самым быстрым микропроцессором IBM. Первоначально он имел время цикла 6,5 наносекунд, что соответствует тактовой частоте 154 МГц. В 1996 году мы представили еще более быстрые его версии со временем цикла 5,5 наносекунд (182 МГц).

Muskie явно предназначен для использования в системах коммерческих расчетов, а не в технических рабочих станциях. И хотя это не самая последняя наша разработка PowerPC, его стоит рассмотреть подробнее, чтобы понять различия между процес

сорами, предназначенными для коммерческих и научно-технических расчетов. Тогда станет ясно, почему было решено сконцентрировать усилия Рочестера на разработке процессоров для коммерческих вычислений (и для AS/400, и для RS/6000), тогда как Остин занимается процессорами для научно-технических расчетов.

Процессор Muskie — одномодульный, многокристальный, конвейерный, суперскалярный и предназначен для старших RISC-моделей AS/400. Это единственный многокристальный процессор семейства PowerPC. Процессор построен по четырех-канальной (4-way) суперскалярной схеме, то есть может выбирать и исполнять до четырех команд за цикл. Кроме того, поддерживаются и многопроцессорные конфигурации.

Рисунок 2.4 Структурная схема процессора Muskie

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

Все шесть кристаллов Muskie используют технологию БиКМОП (Биполярный-КМОП). Биполярная технология имеет высокое быстродействие (в этом ее преимущество) и потребляет большую мощность. Недостаток БиКМОП — большое выделение тепла. Из-за объема рассеиваемого тепла биполярные кристаллы не могут использовать столь же высокую плотность упаковки, как кристаллы КМОП. Технология БиКМОП позволяет размещать на одном кристалле как биполярные цепи (для внешних усилителей), так и цепи КМОП (для схем внутри кристалла).

Вместе со всеми вспомогательными схемами процессор Muskie занимает семь кристаллов. Последние упакованы в один многокристальный модуль, насчитывающий более 25 миллионов транзисторов. Один из кристаллов управляет вводом-выводом, то есть технически не является частью процессора. Прочие шесть кристаллов, составляющих процессор, вместе с соединениями между ними показаны на рисунке 2.4.

БиКМОП отлично подходит для многокристального процессора. Например, известный Intel Pentium Pro выполнен в виде двухкристального модуля и использует технологию БиКМОП по тем же причинам, что и Muskie.

Чтобы понять, почему для реализации данной технологии требуется так много транзисторов, рассмотрим микросхемы процессора подробнее.

В состав шести основных кристаллов, составляющих процессор, входят кристалл процессорного блока PU (Processing Unit), кристалл блока плавающей точки FPU (Floating-Point Unit) и четыре одинаковых кристалла блоков управления основной памятью MSCU (Main Store Control Unit). На кристалле PU расположены кэш команд, блок переходов и блок фиксированной точки. Кэш команд размером 8 килобайт имеет ширину 32 байта. Он может выбирать из памяти за один такт 32 байта (8 команд[ 20 ]). Для передачи больших объемов данных за один такт имеются 32-байтовые тракты данных. Даже регистровый стек блока фиксированной точки рассчитан на загрузку или сохранение четырех 64-разрядных регистров за один такт.

FPU размещается на отдельном кристалле и поддерживает стандарт IEEE для операций с плавающей точкой. Он спроектирован так, что способен выдавать результат в каждом такте, обеспечивая очень высокую производительность команд с плавающей точкой. Четыре команды за такт передаются от кристалла PU на кристалл FPU по 16-байтовой P-шине. Все данные, хранимые в памяти, также пересылаются из PU по P-шине в кэш данных. Данные для FPU выбираются из кэша данных со скоростью 32 байта за такт. Данные из FPU и PU пересылаются в кэш данных по 16-байтовой шине сохранения.

MSCU содержит кэш данных, а также интерфейс памяти. Все четыре кристалла совместно реализуют 256-килобайтовый кэш данных и интерфейсы к шинам данных (см. рисунок 2.4). Обращения к кэшу данных выполняются конвейерно, так что за каждый такт считываются 32 и сохраняются 16 байт данных. MSCU поддерживает многопроцессорные конфигурации, обеспечивая когерентность кэшей разных процессоров.

PU и FPU вместе насчитывают 5 конвейеров, однако в каждом цикле может быть распределено только 4 команды, а именно:

команда перехода (включая операцию над содержимым регистра условия);

команда загрузки/сохранения;

команда арифметики с фиксированной точкой;

команда фиксированной точки (логическая, сдвиг или циклический сдвиг; или команда плавающей точки).

Команды плавающей точки исполняются в FPU, но не могут быть выбраны на выполнение одновременно с командами фиксированной точки для логических операций, сдвига или циклического сдвига, выполняемыми в PU. Обратите внимание, что конвейер загрузки/сохранения выполняет выборку и запись данных как с фиксированной, так и с плавающей точкой. Несколько конвейеров выполняют фрагменты нескольких команд одновременно.

Процессор Muskie также может работать с разделяемой памятью, и таким образом поддерживает симметричное мультипроцессирование. Muskie первого поколения поддерживал конфигурации до 4 процессоров.

Будучи самым быстрым RISC-процессором IBM своего времени, Muskie оптимизирован для нужд коммерческих вычислений. Для иллюстрации приведем некоторые характеристики.

Системы и серверы для коммерческих расчетов должны обрабатывать огромные объемы данных. 16-байтовые (128 бит) и 32-байтовые (256 бит) шины позволяют Muskie справляться с этими задачами. Для сравнения: типичные 8-байтовые (64-разрядные) шины, используемые большинством высокопроизводительных RISC-процессоров, предназначены для рабочих станций, где объем обрабатываемых данных гораздо меньше.

Кэш — обычно слабое место большинства RISC-процессоров, даже если система способна перемещать большие объемы данных. Для устранения этого недостатка в Muskie предусмотрен 256-килобайтовый кэш данных, работающий за один цикл.

Поскольку команда перехода может вызвать простой конвейера, современные RISC-процессоры, подобно суперЭВМ, реализуют некоторую разновидность предсказания переходов. Для большинства RISC-процессоров точность предсказания переходов при выполнении технических задач составляет 80-90 процентов, благодаря тому, что в технических задачах процессор многократно повторяет последовательность команд тела цикла. Для программ подобного типа предсказание переходов работает отлично. В программах для коммерческих задач циклов гораздо меньше и точность предсказания переходов может быть ниже 50 процентов (это соответствует точности случайного выбора). Поэтому, вместо того чтобы пытаться угадать место перехода, Muskie выбирает команды из обоих мест перехода и начинает выполнять их. Данный метод, называемый спекулятивным выполнением (speculative execution), требует очень скоростного кэша (чем Muskie обладает), но зато позволяет достичь по сути стопроцентной точности на задачах любого типа.

Еще один важный аспект коммерческих вычислений — высокие требования к целостности данных и коэффициенту готовности. Muskie реализует коды коррекции ошибок для всех связей за переделами кристаллов. Кроме того, большая часть логики управления и передачи данных на каждом кристалле также содержит различные схемы контроля. Типичный же RISC-процессор для рабочей станции вряд ли способен на что-либо подобное в области определения и исправления ошибок.

Процессоры Cobra первого и второго поколения

Как и Muskie, процессоры Cobra имеют расширенную 64-разрядную архитектуру PowerPC. Они суперскалярные, что позволяет использовать параллелизм на уровне команд. Функционально оба семейства процессоров исполняют один и тот же набор команд уровня приложений. Некоторые различия между ними заключаются в реализации необязательных команд. Так Cobra предназначается для средних и младших моделей AS/400, поэтому реализация команд, поддерживающих, например, мульти-процессирование, в нем не предусмотрена.

Все четыре модели процессоров Cobra разработаны в Эндикотте. В системах AS/ 400, объявленных в 1995 году, используются Cobra-4 и Cobra-CR (CR расшифровывается как «cost reduced» — «цена уменьшена»). Cobra-CR — это Cobra-4, но с возможностью работать только на частоте 50 МГц, самой низкой для этого процессора[ 21 ].

Специально для тестирования нового программного обеспечения операционной системы команда проектировщиков в Эндикотте разработала вариант Cobra-0. Он никогда не применялся в AS/400.

Существовала также версия Cobra-Lite, названная так, поскольку в ней отсутствуют 17 обязательных команд PowerPC[ 22 ]. Ее разработала небольшая группа из Рочестера для системы Advanced 36, анонсированной в 1994 году.

При разработке процессоров Cobra ставилась задача объединить процессор и интерфейс памяти на одном кристалле, который, в результате, содержит 4,7 миллиона транзисторов. Интерфейс шины ввода-вывода располагается на отдельном кристалле, что позволяет использовать процессор с разными интерфейсами ввода-вывода. Cobra использует КМОП, а не БиКМОП, а точнее — технологию, названную IBM CMOS-5L. В результате, процессор рассеивает меньше тепла, чем Muskie, и меньше его нуждается в охлаждении. Только процессоры Cobra помещаются в корпуса небольшого размера, изготовленные для Advanced Series в 1994 году.

Подобно Muskie, Cobra имеет 5 конвейеров, но за один цикл может распределять не более трех команд (то есть выполнен по трехканальной суперскалярной схеме). Это команды:

перехода (включая команду регистра условия);

загрузки/сохранения;

арифметики с фиксированной точкой (включая логические команды, команды сдвига и циклического сдвига), или команда плавающей точки, или команда регистра условия.

Три конвейера (фиксированной точки, плавающей точки и команд регистра условия) совместно используют третий слот диспетчирования команд.

Первые процессоры Cobra работали на тактовых частотах 50 и 77 МГц, но их конструкция, как уже упоминалось, допускает и более высокие частоты. Для поддержания подобной скорости Cobra имеет 4-килобайтный внутренний (на кристалле) кэш команд и 8-килобайтный (также внутренний) кэш данных. По сравнению с Muskie, это не очень много. Большой кэш трудно разместить в однокристальном процессоре, поэтому процессоры, подобные Cobra, используют иерархию кэшей. Маленькие внутренние кэши (называемые кэшами первого уровня или кэшами L1) дополняются большим по размеру внешним кэшем (кэш второго уровня или L2). Cobra может работать с внешним (на отдельной микросхеме) кэшем L2 размером 1 мегабайт.

Процессоры третьего поколения Apache

Модели AS/400 1997 года используют новый дизайн процессора. Этот однокристальный процессор PowerPC, разработанный в Рочестере и названный Apache. Он предназначен для средних и старших моделей AS/400е. Младшие модели серии по-прежнему используют процессор Cobra.

Apache можно считать процессором третьего поколения. В его основе — процессор Cobra, улучшенный и оснащенный новыми возможностями, например поддержки многопроцессорных систем. Apache — первый однокристальный процессор AS/ 400, которому по силам поддержка конфигурации SMP до 12 процессоров (даже Muskie поддерживал лишь четырехпроцессорные конфигурации).

В отличие от Cobra или Muskie, Apache полностью реализует архитектуру PowerPC. Он использует режим активных тегов для поддержки одноуровневой памяти AS/400 и режим неактивных тегов — для поддержки стандартной модели адресации PowerPC; а также стандартные шины адреса и данных PowerPC 6хх — для соединений за пределами кристалла. Так что Apache можно использовать с любой вспомогательной микросхемой, разработанной для семейства процессоров PowerPC 6хх. (О том, как это позволило преобразовать структуру ввода-вывода компьютеров серии AS/400е мы поговорим подробней в главе 10). Apache — первый из когда-либо разработанных в Рочестере процессоров, который может использоваться вне рочес-терских систем. Процессоры Apache используются как в RS/6000, так и AS/400е.

Рисунок 2.5 Структурная схема процессора Apache

Как и Cobra, Apache — однокристальный, 64-разрядный суперскалярный RISC-процессор (его структурная схема — на рисунке 2.5). Он реализован по новейшей технологии IBM CMOS-5S, что позволяет достичь большей плотности упаковки на кристалле, а также времени цикла в 8,0 наносекунд (125 МГц), хотя в некоторых моделях AS/400е используются более медленные версии. Технология КМОП значительно сокращает объем рассеиваемого тепла, который нужно отводить от процессора. В результате, на одной плате может быть установлено до четырех процессоров Apache.

В новом процессоре наиболее значительны изменения в подсистеме памяти. О том, как системы с Apache используют совершенно новую подсистему памяти, предназначенную для пересылки больших объемов данных без замедления работы, читайте в следующем разделе.

Несмотря на то, что время цикла у Apache не столь мало как в Muskie, новая подсистема памяти повышает масштабируемость Apache для конфигураций SMP, что позволяет создать еще более производительные модели AS/400е.

Прежде чем продолжить сугубо технический разговор, хочу представить вам новые корпуса, появившиеся вместе с процессорами Apache. Три оригинальных черных корпуса AS/400 Advanced Series (известные как Apex, Cedar Key и Key Largo) были заменены на два новых, также черных, корпуса (Millennium и Mako). Корпус для Advanced Entry (Eiger) остался тем же.

Мы изменили дизайн корпуса по нескольким причинам. Средние модели серии AS/400 поддерживают конфигурации SMP. Корпус Millennium допускает установку до четырех процессоров Apache, а корпус Mako для старших моделей — до 12 процессоров. (В прежний корпус для старших моделей (Key Largo) помещалось до четырех процессоров Muskie). Корпус Mako гораздо выше (около полутора метров, напоминает оригинальные белые стойки AS/400) и кроме дюжины процессоров в нем есть место для большего объема основной памяти и большего числа дисков. Новые корпуса, которые предполагается использовать в серии AS/400е до 2000 года, были разработаны совместно с подразделением RS/6000 для оптимизации общности компонентов этих систем.

О Процессоры четвертого и следующих поколений

Итак, мы рассмотрели процессор Muskie и то, каким образом он производит коммерческие вычисления, обрабатывая большие объемы данных. Четырехканальная суперскалярная архитектура, а также шины шириной 16 байт (128 бит) и 32 байта (256 бит) ясно свидетельствуют, что Muskie создан для обработки больших объемов данных и команд. А теперь представьте себе, процессор Muskie, упакованный вместе с набором 64-килобайтных кэшей для команд и данных в одну микросхему КМОП. Добавьте к этому полную архитектуру PowerPC процессора Apache и возможность поддерживать конфигурации с 12 или даже 16 процессорами. Что получилось? Конечно, это наш процессор четвертого поколения Northstar.

Сегодня можно уверенно сказать, что через несколько лет на первый план выйдут однокристальные КМОП-процессоры, помещенные в новые черные корпуса. Мы также знаем, что они будут использовать преимущества новой подсистемы памяти, впервые появившейся в Apache.

А впрочем, давайте отложим обсуждение процессоров будущего до главы 12. Там мы рассмотрим некоторые новейшие технологии, включая те, которые сегодня разрабатывает IBM для процессоров AS/400.

О Подсистема памяти

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

В 1991 году я купил новую IBM PC для домашних нужд. В ней был установлен процессор Intel 386 20 МГц, 70-наносекундная память и жесткий диск с временем доступа 16 миллисекунд. Маломощный процессор 386 не долго меня устраивал; поэтому я, как и многие другие, начал бесконечную гонку за новейшей аппаратурой, приобретая последовательно системы с процессорами 486 и Pentium. В последнем купленном мною компьютере (который уже тоже устарел) установлены процессоры Pentium Pro 200 МГц, 60-наносекундная память и жесткие диски со временем доступа 8,5 миллисекунд.

Да, за последние несколько лет разрыв в скорости между процессором и памятью-вводом/выводом вырос невероятно. Теперь вполне возможна ситуация, когда память и ввод-вывод не смогут поставлять достаточно информации для поддержания загрузки процессора, и последний будет проводить множество своих высокоскоростных циклов в ожидании выборки команд или данных.

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

Кэши эффективны благодаря тому, что большинство программ обладают так называемыми пространственной и временной локализацией. Это означает, что программа, скорее всего, обратится к команде или элементу данных, расположенным в памяти недалеко от места последнего обращения (пространственная локализация); а также что такой доступ произойдет через короткий отрезок времени (временная локализация). Нетрудно предположить, некоторые программы обладают большей степенью локализации, чем другие. Программа, предполагающая выполнение многих циклов или большой объем повторной обработки одних и тех же данных, имеет очень высокую степень локализации. Приложения для коммерческих расчетов, наоборот, выполняют мало обработки такого сорта, и имеют несколько меньшую степень локализации. Большие кэши и иерархия кэшей могут обеспечить загрузку процессора данными и командами даже при низких уровнях локализации.

При использовании иерархии кэшей происходит следующее: если нужная процессору информация отсутствует в кэше L1, процессор обращается к кэшу L2. Если информация не найдена и там, то происходит обращение к основной памяти. Пока идет поиск информации и выборка ее в регистр, процессор простаивает. Обычно это называют циклами простоя (stall cycles) процессора. В том случае, если информации нет даже в основной памяти и система должна обратиться к диску, процессор не ждет, а переключается на выполнение другой задачи в системе. Такую ситуацию обычно называют страничной ошибкой (page fault). Подробней мы поговорим об этом в главе 8.

Высокая производительность Muskie достигается с помощью небольшого 8-кило-байтного кэша команд L1 и 256-килобайтного кэша данных L1. Большой кэш данных реализован на четырех отдельных 64-килобайтных микросхемах памяти высокого быстродействия. Будучи однокристальными процессорами, Cobra и Apache имеют гораздо меньшие внутренние кэши L1 (4К и 8К для команд и данных соответственно). Эти внутренние кэши дополняются кэшами L2 большего размера, выполненными в виде отдельных микросхем. Часть производительности Apache достигается за счет очень больших кэшей L2 объемом от 4 до 8 мегабайт.

Несмотря на использование больших кэшей и иерархии кэшей, большинство процессоров все равно тратят много циклов простоя, ожидая выборки из памяти. Проблема заключается в шине между процессором и основной памятью. Большая часть систем, включая ранние AS/400, имеют одну такую шину, обычно высокоскоростную, но все равно работающую медленнее самого процессора. Например, мой Intel Pentium Pro 200 МГц работает с шиной памяти 66 МГц. Это означает, что при обращении к памяти процессор простаивает по три цикла на каждый цикл шины. Легко понять, что таких циклов простоя может быть много.

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

Эта борьба за шину памяти приводит к уменьшению производительности при добавлении к системе SMP каждого нового процессора. Например, добавление второго процессора не позволит увеличить общую производительность на 100 процентов; фактическое увеличение будет несколько меньшим из-за борьбы за память. Добавление третьего и четвертого процессора еще сильнее сократит прирост производительности на один процессор. А когда дело дойдет до восьми и более процессоров, рост производительности системы SMP может и вовсе прекратиться.

Организация памяти

Давайте проведем краткий обзор организаций памяти для многопроцессорных систем. Нас интересуют три схемы организации памяти: централизованная разделяемая память, распределенная память и распределенная разделяемая память.

Машина с централизованной разделяемой памятью предоставляет центральную память для использования всеми процессорами. Обычно, к такой разделяемой памяти подключены посредством одной шины несколько десятков процессоров. Подобная организация называется SMP (ее мы рассматривали выше). Преимущества SMP в том, что все процессоры используют общую память, и время необходимое для доступа к любой части этой памяти, для них одинаково. Поэтому конфигурации SMP часто называют машинами с однородным доступом к памяти UMA (uniform memory access). Недостаток SMP — в ограниченности максимально поддерживаемого числа процессоров.

В машинах с распределенной памятью последняя поделена между несколькими узлами, каждый из которых содержит несколько процессоров, соединенных с памятью узла как в SMP. Пример — кластер AS/400 OptiConnect (подробнее см. главу 6). Иногда машины с распределенной памятью называют архитектурами без разделения (shared-nothing), так как память не разделяется между узлами, а для связи между ними используется передача сообщений. Преимущество разделяемой памяти в том, что она может быть очень большой, если такое разделение памяти не требуется приложениям.

Если каждый процессор в машине с распределенной памятью может выполнять одну и ту же операцию или одну и ту же программу над множеством независимых друг от друга наборов данных, то подобная конфигурация называется процессором с массовым параллелизмом MPP (massively parallel processor). Пример — система MPP в IBM SP2, использующая по одному процессору на узел[ 23 ]. У SP2 также очень хороший механизм передачи сообщений, позволяющий процессорам быстро обмениваться информацией друг с другом. Системы MPP могут насчитывать тысячи процессоров; их недостаток в том, что такая архитектура полезна только для некоторых типов приложений, таких как параллельная обработка баз данных или научных вычислений (то есть там, где совместное использование данных не требуется).

Третья конфигурация — с распределенной разделяемой памятью, представляет собой вариант распределенной памяти. Здесь все узлы, состоящие из одного или нескольких процессоров, подключенных по схеме SMP, используют общее адресное пространство. Отличие этой конфигурации от машины с распределенной памятью в том, что здесь любой процессор может обратиться к любому участку памяти. Однако, время обращения к разным участкам памяти для каждого процессора различно в зависимости от того, где участок физически расположен в кластере. По этой причине такие конфигурации еще называют машинами с неоднородным доступом к памяти NUMA (non-uniform memory access). Мы рассмотрим NUMA в главе 12.

Это отступление от основной линии повествования здесь для того, чтобы помочь Вам, читатель, понять новую подсистему памяти, используемую сейчас в серии AS/ 400е. Эта подсистема разработана для конфигурации SMP, так как последняя наилучшим образом подходит для решения коммерческих задач, когда процессорам требуется использовать память совместно. Но Вы увидите, что она может использоваться и с другими конфигурациями памяти.

Перекрестные переключатели

В рамках начавшейся в 1995 году десятилетней программы ASCI (Accelerated Strategic Computing Initiative) министерство энергетики США DOE (Department of Energy) запросило у производителей компьютеров предложения по созданию самых мощных на сегодня ЭВМ. Задача ACSI — разработка «триллионных» компьютеров, которые могут быть использованы в том числе для моделирования ядерных испытаний. Предполагается, что триллионные (tera-scale) вычисления (таково официальное название для триллиона операций в секунду) будут широко применяться в коммерческих и научных приложениях в следующем столетии. Такие компьютеры создаются в трех национальных лабораториях DOE, связанных с проектом ASCI.

На первом этапе проекта ASCI — ASCI Option Red — рассматривалась большая конфигурация MPP с процессорами, организованными по традиционной модели распределенной памяти. Intel получил контракт на разработку компьютера с 9 072 процессорами Pentium Pro, 283 гигабайтами памяти и двумя терабайтами дискового пространства. Эта система имеет архитектуру MPP без разделения. Испытания новой системы происходили в национальной лаборатории Сандиа (Sandia), штат Нью-Мехи-ко. Ставилась задача — Сандиа (Sandia), «выжать» из единственного в своем роде компьютера, стоимостью в 55 миллионов долларов, триллион операций с плавающей точкой в секунду (один терафлоп). В декабре 1996 компьютер Intel DOE достиг этой цели.

DOE также хотело устранить ограничения двух распространенных многопроцессорных архитектур (SMP и MPP). Как мы уже говорили, системы SMP использующие шины, не масштабируются больше 32 процессоров, но отлично работают для большинства приложений. Схемы MPP сложнее в программировании и подходят только для некоторых классов приложений. Кроме того, их работа сильно замедляется при необходимости доступа к данным, разбросанным по системе. Поэтому DOE предложила новый проект масштабируемого SMP, названного ASCI Option Blue.

Контракты на создание этих систем к концу 1998 года получили две компании, чьи предложения были самыми обещающими: IBM и Cray Research, которая была приобретена SGI (Silicon Graphics Incorporated). Машина IBM названная ASCI Blue Pacific будет установлена в национальной лаборатории имени. Лоуренса (Lawrence) в Ливер-море (Livermore), штат Калифорния, а машина SGI/Cray, получившая имя ASCI Blue Mountain — в национальной лаборатории в Лос-Аламосе (Los Alamos), штат Нью-Ме-хико. Задача обоих компьютеров Option Blue — достичь производительности более 3 терафлоп.

В проекте IBM используются компактные узлы SMP с восемью процессорами; эти узлы соединяются с помощью переключателей передачи сообщений SP2. Проект SGI/

Cray более сложен и включает в себя комбинацию соединений и технологий операционных систем с целью создания образа единой SMP-подобной машины. И хотя физически данные будут распределены по системе, это будет архитектура NUMA.

Компьютер IBM ASCI Blue Pacific будет содержать 512 8-процессорных узлов SMP, 4 096 сверхвысокопроизводительных процессоров PowerPC. Процессор, предназначенный для версии Belatrix Остина, назван 630. Он имеет высокую производительность для вычислений с плавающей точкой и в точности соответствует типу проблем, решать которые призван компьютер DOE.

Для связи между узлами в ASCI Blue Pacific планируется новый высокоскоростной переключатель передачи сообщений типа SP2. Подсистема памяти, позволяющая процессорам внутри узла эффективно использовать память, будет использовать новый 128-разрядный перекрестный переключатель (cross-bar switch)[ 24 ]. Подсистема памяти на основе таких переключателей позволяет нескольким процессорам обращаться к памяти узла параллельно и обеспечивает конфигурацию UMA, где устранена проблема, присущая шине памяти в большинстве конфигураций SMP.

Я упомянул о проекте DOE для того чтобы рассказать о новой подсистеме памяти, используемой в узлах SMP ASCI Blue Pacific. Первая подсистема UMA, использующая 128-разрядный перекрестный переключатель, была разработана в Рочестере. Аналогичная схема используется в настоящее время в компьютерах SMP Apache. Вместо одной шины между памятью и кэшем второго уровня, как в предыдущих системах SMP AS/400, в Apache применены перекрестные переключатели. Благодаря поддержке нескольких параллельных обращений к памяти за один цикл, возможна пересылка больших объемов данных между кэшем и разделяемой памятью, что позволяет поддерживать загрузку процессоров в больших конфигурациях SMP.

Пример подобной конфигурации с двенадцатью процессорами Вы можете увидеть на рисунке 2.6. На одной плате — четыре процессора Apache вместе с четырьмя кэшами L2. В 12-процессорной конфигурации установлено три таких платы. Размещенные на платах кэши L2 размером 4 или 8 мегабайт обладают цикличностью в 8 наносекунд. Таким образом, за один цикл процессора между кэшем второго уровня и кэшем данных или команд первого уровня в микросхеме Apache может быть передано 16 байтов (см. рисунок 2.5).

Основная память в данной конфигурации может достигать 20 гигабайт, каждая плата памяти — содержать до гигабайта, так что на рисунке 2.6 показаны 20 таких плат. Обратите внимание на наличие четырех банков памяти с одинаковым числом плат в каждом, что позволяет обеспечить прослоенную память (memory interleaving) — технический прием, при котором открывается доступ к последовательным блокам данных памяти через разные банки. Например, если каждая плата памяти имеет 8-байтовый интерфейс, то одновременно из четырех банков памяти может быть считано 32 последовательных байта (байты 0-7 из банка 1, байты 8-15 из банка 2 и т. д.).

Четыре перекрестных переключателя подсистемы памяти UMA обеспечивают соединение между кэшами второго уровня и платами основной памяти. Три шины данных 6хх — по одной на каждую плату процессора — соединяют 12 процессоров с каждым из четырех переключателей. Эти 128-разрядные шины данных имеют время цикла 12 наносекунд (в полтора раза больше времени цикла процессора). Дополнительная шина данных 6хх соединяет с каждым из переключателей памяти подсистему ввода-вывода. У каждого переключателя — два независимых 128-разрядных интерфейса к платам памяти.

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

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

Также, обратите внимание, что переключатели используются только линиями данных. Линии адресах всех кэшей второго уровня (показанные на рисунке как адресные линии 6хх) общие, что позволяет обычное отслеживание адресов, иначе называемое снупингом кэша (cache snooping) — прием, при котором каждый контроллер кэша L2 постоянно отслеживает все адреса, передаваемые по общей адресной шине. Кроме того, контроллеры проверяют, содержится ли адрес на шине в их кэше. Если это так, то соответствующие данные кэша становятся недействительными. Таким образом достигается когерентность информации во всех кэшах, ведь общие данные могут быть изменены одновременно не более чем одним процессором.

На рисунке 2.6 также показана общая подсистема ввода-вывода. Для подключения устройства расширения ввода-вывода к корпусу Mako, в котором размещается 12-процессорная конфигурация, используется SAN (System Area Network). Два таких интерфейса показаны на рисунке. В главе 10 мы рассмотрим использование SAN для поддержки разных интерфейсов ввода-вывода в AS/400е и соединения этих систем друг с другом.

Рисунок 2.6 12-конфигурация SMP

Итак, причина использования перекрестных переключателей — стремление повысить эффективность, или, иначе говоря, процентный рост производительности SMP при добавлении нового процессора в конфигурацию. Во многих системах с разделяемой памятью эта эффективность равна примерно 70 процентам при использовании от четырех до восьми процессоров.[ 25 ] Благодаря новой подсистеме памяти, процессоры Apache должны поднять эффективность до 85—90 процентов.

Будущее переключателей памяти

Если используются иерархии кэшей, то почему бы не использовать иерархии переключателей? Фактически, именно это и произойдет в будущем. Мы рассмотрели пример, где каждый процессор был соединен посредством шины 6хх с каждым из четырех переключателей. А ведь вместо этого можно установить на каждый четырех процессорный узел один переключатель, который, логично назвать контроллером узла. Такие контроллеры могут быть подключены к набору переключателей, которые, в свою очередь, подключаются к банку плат памяти. Можно также подключить контроллеры узлов к нескольким наборам переключателей, а каждый из этих наборов — к отдельным банкам памяти. Таким образом будет получена очень большая конфигурация SMP. Вспомните этот разговор после выхода четвертого поколения процессоров Рочестера!

Вы еще не забыли про компьютер IBM ASCI Blue Pacific? В нем будет 512 процессорных узлов по восемь процессоров в каждом и подсистема памяти UMA на переключателях. Не следует ожидать в скором времени появления столь мощной версии AS/400, но разве не приятно осознавать, что такая конфигурация возможна, даже если и не очень практична? В конце концов, кодовым названием System/38 было Pacific[ 26 ], и мы действительно собирались создать по-настоящему большую систему. Ну что ж, посмотрим, как будут выглядеть рочестерские процессоры PowerPC следующего поколения...

Выводы

Сегодня 64-разрядный процессор стал стандартом в компьютерной промышленности. Все RISC-процессоры AS/400 — современные, 64-разрядные, способные обеспечить функциональные возможности и производительность, необходимую для коммерческих систем и серверов. Мы считаем, что семейство RISC-процессоров PowerPC приведет AS/400 в следующее столетие.

Глава 3

System Licensed Internal Code (SLIC) —сердце AS/400

Часто возникает некая терминологическая путаница: что, собственно, является операционной системой AS/400? Первое, что приходит в голову — ну, конечно, это Operating System/400 (OS/400); в конце концов, иначе ее не называли бы так. И все же такой ответ неверен. OS/400 нельзя признать операционной системой AS/400, так как в ней не предусмотрены большинство функций, присущих другим ОС.

В главе 1 мы определили ОС как набор программ, управляющих системными ресурсами и предоставляющих базу для написания прикладных программ. Мы также оговорили, что законченный набор API для написания приложений для AS/400 — это MI, высокоуровневый машинный интерфейс. Таким образом, на вторую часть вопроса мы ответили. Осталось решить, где же находятся программы, управляющие системными ресурсами.

И снова ответ «OS/400» будет неверен. Компоненты традиционной ОС выполняют такие функции как управление памятью, процессами, программами и вводом-выводом. Но, обычно, эти низкоуровневые функции сильно зависят от аппаратуры и тесно связаны с нижележащими физическими структурами. Например, компонент управления памятью должен «знать» точную конфигурацию и характеристики иерархии памяти. Независящий от технологии интерфейс MI не обладает этими качествами. Следовательно, управление памятью должно осуществляться ниже MI, OS/400 же, наоборот, расположена выше. Следовательно, ни одна из таких аппаратно-зависимых компонент не может быть в ее составе, этого не допускает основное условие задачи — независимость от технологии.

Итак, благодаря расположению аппаратно-зависимых компонентов ниже MI, последний защищает прикладные программы и OS/400 от аппаратных изменений. ПО операционной системы, расположенное ниже MI, называется LIC (licensed internal code).

Давайте еще раз взглянем на структуру AS/400. Теперь очевидно: OS/400 состоит из объектов и программ поверх MI, а LIC составляют структуры данных и программы ниже MI. Таким образом, LIC связывает MI и аппаратуру. Фактически, ОС AS/ 400 — сочетание OS/400 и LIC. Получается, что AS/400 представляет собой пирог, в котором OS/400 играет роль глазури, а LIC — начинки между слоями.

В последние годы такую нижнюю часть ОС в других системах стали называть ядром. Есть много определений того, что именно относится к ядру операционной системы. Некоторые педанты могли бы сказать, что LIC содержит гораздо больше функций операционной системы, чем, обычное ядро. И все же термин ядро наиболее удобнен для описания функций ОС, реализованных ниже MI.

Разделяй и властвуй

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

Рискуя забежать вперед (подробно мы рассмотрим MI в главе 4) должен отметить, что, говоря о разделении на OS/400 и LIC, я имею в виду объекты MI, реализованные в LIC. Позже мы подробней остановимся на системных объектах MI, реализованных в LIC, и на объектах OS/400, реализованных только MI.

Конечно, все функции OS/400 присутствуют в LIC в том смысле, что они должны использовать MI для обращения к аппаратуре. Но часто инструкция на ЯВУ после преобразования в соответствующую форму MI транслируется в команды PowerPC (или старого IMPI) напрямую, без каких-то особых структур данных или вызовов процедур LIC. Считать, что некоторая системная функция реализована OS/400, а не LIC, можно в тех случаях, если реализующий ее код видим OS/400 и необходимые структуры данных находятся в объектах OS/400 или в их видимых частях.

На рисунке 3.1 показано распределение функций ОС между OS/400 и LIC. Некоторые функции, такие как управление планированием заданий, могут быть реализованы в основном в OS/400, так как мало зависят от аппаратуры. Другие, такие как поддержка устройств — частично в OS/400, а частично в LIC. Общие характеристики устройств могут поддерживаться OS/400. Например, информация о том, что устройство является принтером, не привязывает прикладную программу к конкретному принтеру. А вот информация о деталях потока данных принтера вызывает подобную привязку и должна использоваться в LIC, ниже MI.

Рисунок 3.1 Распределение функций AS/400

Некоторые аппаратно-независимые функции ОС также реализованы ниже MI, например, защита. Эта функция не зависит от аппаратуры, и таким образом может быть осуществлена целиком в OS/400 поверх MI. Однако реализация части защиты ниже MI обусловлена требованиями безопасности. Подробнее о том, как осуществляется общесистемная защита в OS/400, а контроль доступа к системным ресурсам — в LIC, мы поговорим в главе 7.

Подобно защите, большинство функций ОС реализованы частично над, а частично — под MI. Даже отдельный компонент некоторой функции ОС может быть реализован по обе стороны этой границы. На рисунке 3.1 показаны некоторые компоненты базы данных и их распределение относительно MI.

Другая причина расположения некоторой функции или части ее ниже MI — производительность. Общий принцип таков: чем более функция аппаратно-зависима, тем лучше ее можно настроить для максимальной производительности. Реализация ниже MI не гарантирует повышение производительности для всех функций, но в некоторых случаях может помочь. Недостаток такого подхода — увеличение объема кода ОС, зависящего от аппаратуры.

Микрокод

Ранее микропрограммирование было определено как технический прием, при котором программирование внутреннего компьютера служит цели эмуляции операций внешней вычислительной архитектуры. Соответствующее ПО часто называют микрокодом.

В System/38 было два разделенных IMPI слоя микрокода ниже MI: горизонтальный микрокод HMC (Horizontal Microcode) и вертикальный микрокод VMC (Vertical Microcode)[ 27 ]. Самым низким уровнем был HMC, использовавший специализированный набор микрокоманд, исполняемый аппаратурой процессора непосредственно. Он содержал микропрограммируемый эмулятор, выполнявший команды IMPI. В состав HMC были также включены некоторые функции ОС самого низкого уровня. HMC был спроектирован так, чтобы обеспечить высокопроизводительный параллелизм работы процессора. Из-за этого ЯВУ для написания такого кода не существовало, а программирование было очень сложным и требовало много времени.

Вторым слоем, расположенным под MI, но над IMPI, был VMC. В этом слое содержались те аппаратно-зависимые функции ОС, которые не были реализованы в HMC. VMC был написан частично на специализированном ЯВУ, разработанным внутри IBM для системного программирования, и частично на ассемблере IMPI. Он не был микрокодом в традиционном смысле; а представлял собой самый нижний уровень ПО ОС.

Ядро операционной системы System/38 было названо микрокодом во избежание коммерческих проблем, типичных для 60-х годов. Тогда среди компьютерных гигантов, включая IBM, была распространена следующая практика: связывать получение системного ПО с требованием покупать фирменную аппаратуру. Так продолжалось до тех пор, пока различные фирмы ни создали множество компьютеров, совместимых с мэйнфреймами IBM (сегодня, мы назвали бы их клонами), для продажи по более низкой цене. Производители совместимой аппаратуры получали прибыль только в том случае, если бы покупатели могли приобретать ОС IBM без аппаратных средств. Под угрозами судебных преследований IBM согласилась в будущем не привязывать ПО к своим компьютерам.

С System/38 проблема связанных продаж ПО и аппаратуры возникла вновь. Мы хотели получить систему, единственным внешним интерфейсом которой был бы MI. Если бы мы продавали только аппаратные средства, то потеряли бы обеспеченную

MI независимость от технологии. Для выхода на рынок годился только законченный машинный продукт MP (Machine Product), который бы содержал аппаратные средства плюс ядро ОС.

Чтобы выйти из положения, ядро назвали микрокодом, позаимствовав этот термин у разработчиков проекта IBM Future Systems, которые еще в начале 70-х также пытались объединить некоторые функции ПО с аппаратурой. Так как микрокод рассматривался как часть аппаратуры, то тем самым мы не нарушали соглашения и были чисты перед законом. Все затраты по разработке VMC должны были быть отнесены на аппаратные средства. По тем же соображениям для написания VMC необходимо было создать проектную организацию, отдельную от группы программирования. Именно этим и объясняются разные названия сходных функций и структур в OS/400 и VMC (см. последующие главы).

С появлением AS/400 названия двух слоев микрокода были изменены. Сегодня наши заказчики могут покупать аппаратное, но не программное обеспечение. Вместо этого они приобретают лицензию на использование ПО (иногда — только для определенной системы) и не могут изменять, копировать или перепродавать его, если это не разрешено лицензией. Микрокод же — часть аппаратуры, а следовательно, покупатель может владеть им. Так как при объявлении AS/400 вопрос о связывании более не стоял (сегодня мы продаем даже OS/400 в едином комплекте с аппаратурой), то IBM решила переименовать микрокод System/38. Таким образом, у AS/400 имеется вертикальный LIC VLIC (Vertical Licensed Internal Code) и горизонтальный LICHLIC (Horizontal Licensed Internal Code).

С появлением новых RISC-процессоров потребовалось еще одно изменение названия. HLIC содержал микропрограммируемый эмулятор, необходимый для реализации IMPI. Так как у RISC-процессора микропрограммируемого эмулятора нет, то нет и HLIC, остается только VLIC. В связи с этим при переходе на RISC-процессоры, функции ОС, ранее выполняемые в HLIC, были переписаны для VLIC. И когда остался единственный слой внутреннего кода, мы с радостью отбросили, наконец, бессмысленные названия «вертикальный» и «горизонтальный».

Впереди скользкая дорога

Вопрос: Что содержит более трех миллионов строк кода, создано усилиями 200 программистов и имеет имя, вызывающее в памяти зимнюю дорогу в Миннесоте?

Ответ: Внутренний код для систем с RISC-процессором — SLIC (System Licensed Internal Code). Хотя, несомненно, придумавшие это имя разработчики имели в виду значение слова slick на сленге («чудесный», «замечательный», «первоклассный»), а не свойства зимних миннесотских дорог[ 28 ].

Когда в 1991 году в Рочестере начались работы над RISC-процессором, потребовалось внести множество изменений в LIC, расположенный под MI. Некоторые компоненты (но не все!) должны были быть полностью переработаны. Большая часть существующего LIC также требовала реструктуризации. Этот код уже претерпевал частые изменения и модернизации при создании новых моделей System/38 и AS/400.

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

До перехода на RISC-процессоры нам нужно было еще выпустить три новых версии VLIC, из-за чего мы не могли полностью переключиться на SLIC. Поэтому для создания новой ОС было решено создать специальное подразделение во главе с Майком Томашеком. Входившие в его состав инженеры могли выбирать любые методы разработки по своему усмотрению.

На совещании по выработке плана действий эта группа рассмотрела два подхода к модернизации LIC. Первый состоял в том, чтобы заново спроектировать и написать низкоуровневые компоненты, затронутые изменением процессора. Второй — переместить эти затронутые компоненты в аппаратуру RISC с минимальными изменениями. Данный тип миграции ПО без изменения логики работы программы часто называется переносом. Все остальные компоненты, не затронутые изменением процессора, такие как база данных, должны были быть перенесены с минимально возможными модификациями.

Майк и его команда решили перепроектировать и переписать затронутые компоненты заново. Это было нелегким решением, так как большая часть низкоуровневого кода основывалась еще на первоначальном проекте System/38 и интенсивно настраивалась для повышения производительности в течение 15 версий системного ПО. Не все верили в успех: ведь предстояло полностью изменить лишь «начинку» переписываемых компонентов, оставив в неприкосновенности все интерфейсы, чтобы не затронуть переносимые компоненты. Кроме того, надо было учесть возможность расширений ПО в планируемых новых версиях AS/400. В общем, все это напоминало стрельбу по движущейся мишени.

Билл Берг — один из десяти специалистов, рекомендовавших использовать PowerPC для AS/400, — продвигал идею сократить время разработки, использовав объектно-ориентированное программирование (ООП). Объектно-ориентированные языки приобрели популярность конце 80-х как способ быстрого создания программ и уже были достаточно совершенными, чтобы использовать их в таком большом проекте. Билл Армстронг (Bill Armstrong) и Дик Мастейн (Dick Mustain) — также твердые сторонники объектно-ориентированной разработки — были с ним согласны. Пол Мэттисон (Paul Mattison) собрал команду и подготовил план действий. Поддержка ключевых разработчиков также доказала, что новая технология программирования поможет обеспечить делу успех. Кроме того, мы собирались нанять новых людей.

Концепции объектно-ориентированного программирования

Давайте кратко рассмотрим основные элементы и термины ООП. Объект — это основной элемент программы, объединяющий в себе данные и операции над ними. Операция, которую может выполнить объект, иногда называется методом. Внутренняя структура данных и реализация методов объекта скрыта от остальной программы. Это называется инкапсуляцией. Программе доступен только интерфейс объекта. ООП отличается тем, что объединяет операции и данные воедино (при процедурном программировании операции отделены от данных).

Подход ООП предполагает повторное использование ПО. Основной механизм обеспечения повторного использования — класс, представляющий собой шаблон, описывающий все объекты, для которых характерны одинаковые операции и элементы данных. Следовательно, может быть создано много объектов каждого из классов. Часто они называются экземплярами объекта.

Для существующего класса можно создать подклассы путем использования наследования. Наследование позволяет программисту и создавать новые подклассы, и повторного использовать код, а также данные базового класса без их повторения. Вновь полученные подклассы настраиваются так, чтобы соответствовать конкретным потребностям приложения. Способность подклассов одного класса отвечать на одно и то же входящее сообщение по-разному называется полиморфизмом. Полиморфизм объединяет концепции наследования и динамического связывания (dynamic binding).

Наборы объектов, созданные из классов и подклассов, могут быть объединены для построения необходимых сервисов ОС. После определения достаточно сложного набора классов (называемого библиотекой классов), программисты могут использовать классы этого набора, а не программировать заново функции, предоставляемые классами.

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

Среда разработки SLIC

Группа разработчиков должна была выбрать язык программирования. Язык программирования VLIC, называвшийся PL/MP и использовавшийся со времен разработки оригинальной System/38, был основан на языке PL/I. MP в его названии расшифровывается как Machine Product — имя, которое часто использовалось для обозначения аппаратных средств и обоих слоев микрокода. Компилятор PL/MP, как и ассемблер IMPI, генерировал двоичные машинные команды IMPI.

Язык PL/MP не пригоден для ООП, но его по-прежнему использовали для тех компонентов, которые не переписывались. А для остальных был разработан новый компилятор PL/MP, генерировавший двоичный код для PowerPC. Кроме того, было создано специальное средство переноса программ, которое сканировало код, отыскивая зависимости от IMPI, прежде чем преобразовать его в новый PL/MP.

В течение ряда лет мы пытались использовать другие языки при разработке компонентов VLIC. Например, один из наших новейших трансляторов был написан на Modula-2, применялся также язык С. Однако, мы чувствовали, что ни один из них не подходит для проекта, основанного на объектно-ориентированной технологии. Выбор напрашивался сам собой — язык C++. Нам нужно было разрабатывать код ОС очень низкого уровня. Иногда, для достижения оптимальной производительности приходилось прибегать к ассемблеру, и С+ + легче позволял это. Ведь, фактически, язык С++ и есть современный вариант ассемблера[ 30 ].

Другим преимуществом С++ была возможность легко найти людей, его знающих. Для этого проекта нам было нужно много новых программистов, и начался массовый найм. Скоро над проектом SLIC работало более 200 человек.

Для успеха проекта обучения было крайне важно, чтобы вновь набранные сотрудники поскорее изучили внутреннее устройство AS/400[ 31 ], а наши старые работники — программировать на С++. Некоторые уже умели это, но большинство из них использовали С++, как улучшенный С. Нужно было научить каждого объектно-ориентированному подходу. Это стало настоящей проблемой, так как в Рочестере на тот момент не оказалось никого, кто зашел бы дальше прочтения нескольких книг по данной теме. Решение было предложено Крисом Джонсом. Согласовав свои действия с другими руководителями проекта, он нашел стороннего консультанта — эксперта как в объектно-ориентированной технологии, так и в программировании на С++. Никогда ранее мы не обращались «на сторону» по подобным поводам. У IBM были внутренние программы обучения, и персонал, который этим занимался. Разумеется, приглашение на работу чужака было воспринято в штыки. Крис настаивал и убедил-таки руководство нанять консультанта для интенсивного шестинедельного обучения наших сотрудников. Мы даже специально выгородили прямо посередине отдела разработки классную комнату, которая использовалась исключительно для обучения.

Возможность повторных итераций при разработке — фундаментальное преимущество ООП, но при ее использовании трудно оценить, в какой степени мы продвинулись вперед. Прием, который мы использовали для «измерения прогресса», заключался в так называемых BUB (Bring up Bind). Каждый BUB представлял собой группу объектов, реализовывавших четко определенный набор функций ОС, и имевшую общий интерфейс с другими компонентами. Путем сравнения BUB с другими компонентами, мы могли оценить, как продвигается разработка. Кроме того, BUB позволили нам действовать в определенном порядке, а также вызвали переделку известного рекламного лозунга Budweiser: «This BUB's for you»[ 32 ].

Технология ООП не подвела: производительность программистов при разработке SLIC повысилась почти в четыре раза по сравнению с традиционной методикой. В период с июля 1992 года, было создано более миллиона строк кода на С+ + и более 7 000 классов. Считая весь перенесенный код, ниже MI работает более 3 миллионов строк кода ОС.

Затраты на разработку SLIC

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

SLIC содержит 3 миллиона строк надежного кода. (Под надежным имеется в виду код, который всегда должен работать правильно, чтобы обеспечить целостность и защищенность системы.) Так как SLIC — ядро ОС, мы не защищаем один его компонент от другого. Это совершенно обычный подход: ядра большинства ОС защищены от кода, расположенного вне его, но весь код внутри ядра считается надежным.

Если ядро невелико, скажем, состоит из 100 тысяч строк кода, то его целостность очень легко протестировать при каждом изменении. Если же строк 3 миллиона, то такое тестирование становится и сложнее, и дороже. Много лет мы в Рочестере использовали следующий подход: строго ограничивали круг тех, кому позволено работать с ядром, группой разработки и тестирования. Таким образом, код для SLIC могут написать заново только разработчики из Рочестера (впрочем, это достаточно большое число людей). Дополнительно надежность гарантируется тем, что разработчики действуют в условиях жесткой организационной структуры.

У подобного подхода есть и свои недостатки. Неоднократно сторонние организации, включая другие подразделения IBM, запрашивали у нас разрешение написать функции для SLIC. Во всех случаях мы отвечали твердым отказом: если позволить кому-либо написать хотя бы малую часть SLIC, то это может нарушить целостность всей системы, чего мы не допустим. Но следствие такого подхода — то, что создание новых функций SLIC жестко зависит от возможностей наших программистов. Мы практически никогда не можем позаимствовать код у кого-либо еще в IBM, по крайней мере, не на уровне SLIC.

В главе 4 мы рассмотрим, как компиляторы ЯВУ генерируют код PowerPC, исполняемый ниже MI. Мы увидим, что это требует использования компонента SLIC, известного как транслятор. Как и все компоненты SLIC, транслятор надежен, то есть должен всегда генерировать код, чтобы не нарушить целостность или защиту других компонентов системы. Трансляторы также разрабатываются только в подразделении SLIC в Рочестере.

Хорошо, что все функции SLIC работают как единое целое. Так как весь SLIC разрабатывался под одной крышей, мы достигли уровня целостности, о котором можно только мечтать в системах, разработка которых ведется «кусками». Использование общих программных компонентов в разных ОС может значительно сократить затраты, но не даст той интеграции функций, которой обладает AS/400. Что касается общих компонентов, то как мы увидим в следующем разделе, и здесь существует возможность подключения без нарушения целостности.

Технологии ядра в SLIC

В прошлом ядро каждой ОС было уникальным, мало кто брался разрабатывать ядро отдельно от ОС. Однако в середине 80-х годов положение стало меняться. В некоторых университетах, например, в Карнеги-Меллон (Carnegie-Mellon), начали изучение возможности использовать ядро с несколькими ОС. Именно там было спроектировано микроядро Mach, представляющее собой подмножество ядра, и выполняющее функции, необходимые большинству ОС.

Если одно и то же микроядро лежит в основе двух или нескольких ОС, то возможно исполнять эти ОС параллельно на одном и том же процессоре. Более того, такие ОС могут очень эффективно разделять ресурсы и взаимодействовать друг с другом. В последние годы операционные системы, выполняющиеся поверх одного микроядра, стали называть индивидуальностями (personality).

Так как SLIC разрабатывался в качестве нового ядра ОС, имело смысл включить в него технологии для поддержки множественных индивидуальностей. Фактически, большая часть такой поддержки уже имелась в оригинальном LIC. Например, для распределения процессора между ОС микроядро использует механизм передачи сообщений. Аналогичный подход использовался в оригинальной System/38 и был перенесен оттуда на AS/400. Подробно мы рассмотрим этот механизм в главе 9.

В то время, когда мы разрабатывали SLIC, в IBM были проведены исследования в области применения общих компонентов ОС на всех системах IBM, включая использующие процессор PowerPC. Одним из основных предложений было — принять в качестве базовой модели микроядро IBM, сконструированное по принципам микроядра Mach. В SLIC уже имелось большинство технологий микроядра, но возникали сомнения: следует ли нам в качестве всеобщей основы использовать микроядро IBM?. Ответ был совершенно очевиден. Единственно существовавшим в то время было 32-разрядное микроядро. Чтобы использовать это микроядро для AS/400, нужно было бы создать 64-разрядную версию. Перспективы возможности разделения ПО были также довольно туманны, кроме того, оставались вопросы по поводу масштабируемости этого микроядра (сколько пользователей сможет оно поддерживать?). Поэтому мы отвергли мысль использовать его в качестве основы для SLIC. Однако в Рочес-тере была создана группа для разработки 64-разрядных модификаций микроядра IBM с прицелом на будущее. Было также решено включить в SLIC возможности по поддержке множественных индивидуальностей ОС.

Добавление в SLIC поддержки других ОС, на первый взгляд, не имело смысла. Какие еще ОС, кроме OS/400, нам следует поддерживать? Некоторые из нас все понимали, но были вынуждены пойти на небольшую хитрость, чтобы показать, как эта поддержка могла бы работать.

Индивидуальность System/36

В Рочестере была и группа разработчиков, продолжавших оставаться приверженцами System/36. В 1993 году в разгар работ над SLIC у двоих руководителей группы System/36, Дика Мастейна и Стива Дала (Steve Dahl), возникла идея. Почему бы не создать новую System/36? Такая возможность появлялась с переходом AS/400 на RISC и наличием в SLIC поддержки для других ОС. Упомянутые разработчики быстро подготовили предложения по переносу ОС System/36 на RISC-аппаратуру.

В предыдущие несколько лет различные производители по всему миру начали поставлять на рынок программные пакеты, позволявшие клиентам System/36 перейти на RISC-компьютеры: либо на RS/6000 IBM, либо на продукты конкурентов. Беда этих пакетов-«имитаторов» заключалась в том, что они предоставляли только часть возможностей System/36. Пользователям System/36 по-прежнему было необходимо вносить изменения в свои приложения и методы работы, а некоторые из программ для System/36 и вовсе не работали на новом компьютере.

В IBM был принят официальный план перевода пользователей System/36 на AS/ 400. Но лишь немногие заказчики воспользовались этой возможностью, а большинство отвергло ее. Согласно оценкам, более 200 000 System/36 по-прежнему работают в во всем мире. И все же многие в IBM полагали, что переход приверженцев System/ 36 на какую-либо новую платформу IBM — лишь вопрос времени. Не стоит и говорить, что в таких условиях предложение разработчиков о создании новой System/36 не было встречено с особым энтузиазмом.

По счастью, некоторые из рочестерских руководителей всегда хотели проверить новые возможности, и вскоре для разработки новой System/36 была создана «подпольная» группа («skunkwork»), что, впрочем, практиковалось в Рочестере и раньше[ 33 ]. Мы использовали такой трюк для разработки систем, которые не считались стратегическими и, таким образом, не финансировались централизованно. Вспомните, что и сама AS/400 появилась в результате подобной «подпольной» деятельности.

Итак, небольшая группа экспертов по System/36 под руководством Боба Шмидта (Bob Schmidt) вынуждена была скрываться от зорких глаз финансистов. Тем не менее, у Боба не было недостатка в добровольцах. Всего через несколько месяцев работы этой небольшой команды энтузиастов System/36 работала на новом RISC-процессоре. Серия продуктов System/36 получила новое дыхание.

Что-то старое, что-то новое

Процессор оригинальной System/3, появившейся на свет в 1969 году, был полностью реализован аппаратно. Он был очень прост и поддерживал всего 28 команд. Поверх аппаратуры System/3 функционировала ОС вместе со всеми приложениями. С появлением в 1975 году System/32 эта структура претерпела существенные изменения.

Уже в начале 70-х годов в процессе работ над System/38 перевод некоторых функций ОС в микрокод для достижения независимости от технологии был в Рочестере хорошо отлажен. Для поддержки набора команд System/3 в System/32 использовался микропрограммный эмулятор. По соображениям производительности некоторые функции были вынесены из ОС System/3 в микрокод System/32. Таким образом, System/32 и System/38 имели общие черты: некоторые части их ОС были реализованы в микрокоде, хотя и по разным причинам.

System/32 была разработана как система начального уровня и полностью соответствовала этому предназначению. Эмуляция набора команд System/3 выполнялась медленно, производительности процессора не хватало. Однако, процессор System/ 32 отлично выполнял эти функции. Примечательно, что сам он был 16-разрядным, использовал регистры и очень напоминал некоторые ранние RISC-процессоры.

Для повышения производительности System/32 требовались некоторые изменения. Ее процессор хорошо справлялся с выполнением ОС, так что было принято решение оставить его. Но поскольку он слишком медленно выполнял эмуляцию команд System/3, то был добавлен второй процессор, сходный с оригинальным процессором System/3, для исполнения команд последнего непосредственно аппаратурой. Значительная часть ОС была написана с помощью команд System/3 и должна была исполняться на втором процессоре. Так как он выбирал команды из основной памяти, второй процессор был назван MSP (Main Store Processor). Процессор же System/32 выбирал команды из отдельной области памяти, и был переименован в CSP (Control Store Processor). В 1977 была выпущена первая система на двух процессорах, названная System/34.

В 1983 году вслед за System/34 появилась модель System/36. Она по-прежнему использовала двухпроцессорную структуру. Подобно AS/400, чья ОС разбита на две части — OS/400 и SLIC — ОС System/36 также состояла из двух частей. Первая часть под названием SSP (System Support Program) исполнялась на MSP, а другая — на CSP. Старшие модели System/36 имели дополнительные процессоры для выполнения функций ввода-вывода. Они также представляли собой CSP, на которых исполнялись части ОС, управлявшие вводом-выводом. За следующие несколько лет были выпущены новые модели System/36, и все они также использовали два процессора.

В 1993 году разработчики System/36 пришли к выводу, что RISC-процессор, который предназначался для AS/400, достаточно быстр, чтобы эмулировать набор команд MSP без дополнительного процессора. Если соответствующий эмулятор встроить в SLIC вместе со всем кодом CSP, то ОС SSP могла бы выполняться новым RISC-процессором непосредственно. Для этого необходимо было создать эмулятор и переписать код CSP на С++ как часть SLIC.

Интерфейс между оригинальными MSP и CSP был интерфейсом SVC (Supervisor Call). Команда вызова супервизора (SVC) исполняется MSP и представляет собой запрос на выполнение CSP некоторых действий. Концептуально это то же самое, что и исполнение команды на уровне MI для запроса на выполнение некоторых действий SLIC. Разработчики рассудили, что если расширить MI включением интерфейса SVC, то SPP можно будет исполнять поверх MI, что позволит сделать SSP так же независящим от технологии. Соответствующее расширение MI было названо Technology Independent Emulation Interface (интерфейс эмуляции независящий от технологии)[ 34 ]

Приняв решение использовать для выполнения набора команд MSP не отдельный аппаратный процессор, а эмулятор, разработчики получили конструкцию, которая внутренне более походит на System/32, нежели на System/34 или System/36. Как часто происходит, история повторяется. В новом черном корпусе снова живет «bionic desk» (прозвище System/32)!

Advanced 36

Вот так внезапно мы получили совершенно новую System/36, работавшую на 64-разрядной RISC-аппаратуре с использованием ядра SLIC. Более того, это была System/ 36 в чистом виде. В SSP не было никаких изменений, затронувших интерфейсы приложений. Новая система была полностью двоично совместимой с System/36. Для переноса приложения на новую систему не требовалась даже перекомпиляции.

Очевидно, что эта новая индивидуальность System/36 могла бы выполняться на AS/ 400 с переходом на новые RISC-процессоры. Однако была и другая возможность — воссоздать раннюю версию процессора Cobra полностью (процессор, кэш и интерфейс ввода-вывода) на одном кристалле. В Рочестере была организована небольшая группа, которая вскоре получила однокристальный процессор, основывавшийся на дизайне ендикоттовской лаборатории. Этот процессор работал на частоте 50 МГц, что было достаточно быстро для любого приложения System/36. Процессор получил название Cobra-Lite, так как в нем не было реализовано примерно 17 команд из обязательного набора 64-разрядного PowerPC. Данные команды, по большей части для работы с плавающей точкой, были реализованы программно, но это не имело значения. Отсутствовавшие команды, включая комбинированную команду умножения и сложения с плавающей точкой, применяющуюся для матричных вычислений, не использовались в SLIC и не влияли на новую System/36.

IBM подтвердила, что ее завод в Барлингтоне может производить специальные микросхемы в количестве, достаточном для выпуска новых System/36 на RISC-процессорах в конце 1994 года. Мы знали, что можем включить в этот продукт раннюю версию SLIC с новой версией SSP.

Перед нами была непростая дилемма. Можно начать выпуск первого 64-разрядного RISC-компьютера IBM — но это System/36! Мы много лет призывали своих заказчиков отказаться от System/36, а теперь были готовы выпустить ее новую версию на основе самой современной технологии. Принять такое было нелегко. Подразделения IBM по всему миру отвергли новую System/36. Наконец, мы убедили руководство позволить нам самим поговорить с заказчиками и бизнес-партнерами и предоставить рынку решать, следует ли нам объявлять в 1994 году о новой системе. Я делал доклад о новой System/36 на самой большой конференции наших бизнес-партнеров в начале 1994 года. Подавляющее большинство аудитории проголосовало за объявление новой системы. Многие были готовы прямо на месте купить у нас демонстрационную машину. Руководство и службы маркетинга IBM быстро оценили потенциал новой системы. В октябре 1994 года Advanced 36 появилась на рынке, где сразу же стала пользоваться спросом.

Первая модель Advanced 36 исполняла только ОС SSP. Последующие модели могут исполнять OS/400 и SSP параллельно на одном и том же процессоре. Advanced 36 продемонстрировала всю мощь архитектуры AS/400 и ее способность прозрачно интегрировать новую функциональность и даже целую новую ОС. Теперь внутри SLIC каждой RISC-модели AS/400 «живет» System/36. Может, имеет смысл на каждую новую AS/400 приклеивать метку «System/36 Inside»?

Выводы

Интеграция обеспечила уникальные возможности AS/400. Компоненты разработаны для взаимодополняющей совместной работы друг с другом. Интеграция также затрудняет изучение компонентов по отдельности, как в других системах. Например, ранее мы говорили, что защита реализована частично в OS/400 и частично — в SLIC. Изучение только защиты OS/400 не дает полной картины. Сравните это с другими системами, где компонент защиты представляет собой отдельный самодостаточный пакет, работающий поверх ОС.

Рассматривать AS/400 как набор горизонтальных слоев не результативно. Лучше понять систему можно, «делая» ее вертикальные срезы, — то есть изучая конкретную функцию, части которой реализованы в OS/400, в SLIC и в аппаратуре как единое целое.

В следующей главе мы рассмотрим слой MI. Это позволит лучше понять типы функций, реализованных в OS/400 и в SLIC. Мы также увидим, каким образом программа, прежде чем выполняться, компилируется до уровня аппаратуры.

Далее мы поговорим об основных компонентах AS/400 как о ряде вертикальных срезов. После этого Вы увидите, как справедливо в приложении к AS/400 старое изречение: «Целое больше, чем простая сумма частей».

Глава 4

Машинный интерфейс, независимый от технологии

Итак, после того, как к большинству компьютерных систем были добавлены уровни абстракции, их архитектура стала многоуровневой. Главные уровни AS/400 — это архитектура независимого от технологии машинного интерфейса MI (Technology Independent Machine Interface) и архитектура RISC-процессора PowerPC.

Определение архитектуры PowerPC было дано с очевидным уклоном в сторону аппаратуры. Конструкторы микросхем играют важную роль в создании любой процессорной архитектуры — ведь именно они держат в голове массу вариантов ее реализации. Дабы не выйти за пределы возможностей конкретной аппаратуры конкретного кристалла, соблюсти время процессорного цикла, от одних функций им приходится отказываться, другие — определять заново. Это единственно верный подход — ведь в нереализуемой аппаратной архитектуре смысла мало. В то же время архитектура, учитывающая только требования аппаратуры, недолговечна.

Правда, есть и опирающиеся на аппаратуру архитектуры-долгожители. Например, Intel успешно довела свой процессор x86 с начала 80-х до сего дня. Начав с Intel 8086, эта компания продолжает наращивать его функциональные возможности, по мере того как технология позволяет упаковать все больше транзисторов в один кристалл. Семейство процессоров 186, 286, 386, 486, Pentium, Pentium II и Pentium Pro — грандиозный успех Intel.

Для поддержания программной совместимости к оригинальной 16-разрядной архитектуре были добавлены 32-разрядные расширения. С этой же целью новые (1997 год) команды расширений мультимедиа (MMX) используют существующие регистры с плавающей запятой, а не добавляют новые. С целью повысить конкурентоспособность и производительность Intel добавила в процессоры Pentium Pro и Pentium II набор микрокоманд RISC. Каждая CISC-команда x86 реализована в этих процессорах как последовательность RISC-команд. Благодаря использованию RISC-техноло-гии архитектура x86 продолжает жить.

Обзор архитектуры MI

Определение архитектуры MI не привязано к аппаратуре. Это не физический, а логический интерфейс системы. Как уже говорилось в главе 1, архитектура MI предлагает полный набор API для OS/400 и всех приложений. Этот набор полон по определению; то есть ни система, ни приложения в принципе не могут выйти за пределы MI. Единственный способ связи с аппаратурой и некоторым системным ПО ниже MI — через сам MI. Это свойство отличает архитектуру MI от API-центрической архитектуры, где приложения могут обходить API и, следовательно, становиться зависимыми от нижележащих аппаратуры и ПО.

Когда создавалась архитектура MI, термин API еще не был четко определен, так что разработчики называли эти модификации просто командами. Чтобы показать, что интерфейс архитектуры поддерживает как прикладное, так и системное ПО, они выбрали название машинный интерфейс. Так что можно считать, что «I» в аббревиатуре «API» — то же, что и в «MI». API — не что иное, как команды MI.

Вы поражены прозорливостью разработчиков первоначальной архитектуры MI, раз и навсегда определивших набор API, используемый OS/400 и всеми приложениями? Не стоит: они не сделали этого, да и не могли сделать. По мере появления новых приложений в архитектуру MI добавлялись поддерживающие их новые API. Дело в том, что архитектура MI безразмерна, и новые API для поддержки новых приложений или функций операционной системы к ней можно добавлять в любое время. А раз эта архитектура постоянно изменяется, приобретая новые функции, то значит, она никогда не устареет. Так как все предыдущие API остаются при этом нетронутыми, для всех ранее написанных приложений сохраняется защита в границах MI.

Архитектура MI состоит из двух компонентов: набора команд и операндов, над которыми эти команды выполняются. Часть операндов — из битов и байтов — не отличается от тех, что используются в обычных компьютерных архитектурах. Другие представляют собой объекты. Объект — это сложная структура данных, единственная, поддерживаемая в рамках MI.

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

Объект в границах MI — это контейнер, содержащий структуру данных, соответствующую информационному ресурсу. Определенный уровень независимости достигается следующим образом: прикладные и системные программы вместо того, чтобы работать непосредственно со структурой данных через инструкции на уровне битов и байтов, имеют дело лишь с инструкциями, рассматривающими объекты в целом.

Благодаря использованию объектов, прикладному и системному ПО больше не требуется информация о структуре или формате данных. Эта информация хранится в контейнере и невидима за пределами объекта. Поэтому любые изменения в структуре данных не влияют на прикладные или системные программы, и они остаются независимыми от структур нижнего уровня. Такое свойство сокрытия внутренних деталей называется инкапсуляцией. Мы обсудим инкапсуляцию, а также внутреннюю структуру объекта и команды для работы с ними в главе 5, а теперь сосредоточимся на наборе команд архитектуры MI.

Давайте обсудим несколько примеров команд, выполняемых над обычными данными и команд, оперирующих объектами. Поговорим и о том, как компиляторы используют MI для генерации кода, выполняемого аппаратурой, познакомимся с характеристиками MI и программами MI. И наконец, рассмотрим структуру команд MI.

Неисполняемый интерфейс

Команды MI не исполняются аппаратурой непосредственно. Они либо предварительно (до исполнения программы) транслируются в аппаратный набор команд, либо специальный компонент SLIC интерпретирует некоторые команды MI одну за другой. Пример интерпретируемых команд MI — API Advanced 36. Мы называем процесс преобразования команд MI в низкоуровневые аппаратные команды трансляцией, а не компиляцией, так как при этом выполняется лишь часть функций компиляции. Прежде результатом такой трансляции был набор инструкций IMPI — теперь это набор инструкций PowerPC.

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

Структура современного оптимизирующего компилятора показана на рис. 4.1. Обычно, компилятор состоит из двух и более проходов или фаз. Проход — это одна фаза, за которую компилятор считывает и модифицирует всю программу. Термины фаза и проход часто используются как синонимы.

В процессе выполнения каждого прохода компилятор преобразуя программу, понижает уровень ее представления (от более абстрактного к менее). В конечном итоге получается набор команд аппаратуры. Такая структура оптимизирующего компилятора была впервые предложена в 60-х годах для упрощения сложных преобразований, имевших целью получение оптимизированного кода.

Возможности однопроходного компилятора по оптимизации ограничены. Проще говоря, он не может просмотреть код программы вперед и учесть то, что произойдет дальше. «Заглянуть вперед» может многопроходный компилятор. Назначение регистров переменным в зависимости от их связей с другими переменными, запись в память ненужного более содержимого кэша, предварительная выборка операндов — вот лишь некоторые примеры оптимизации, выполняемой многопроходным компилятором.

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

Рисунок 4.1 Структура оптимизирующего компилятора

Первый проход компилятора, показанного на рис. 4.1, часто называют препроцессором (front end) компилятора. Его задача — преобразование текста на ЯВУ в общую промежуточную форму (common intermediate form).

Постпроцессор (back end) компилятора состоит из фаз оптимизации и фазы генерации кода. Препроцессоры зависят от ЯВУ, тогда как постпроцессоры — от аппаратуры. Если общая промежуточная форма независима как от ЯВУ, так и от аппаратуры, то она может использоваться несколькими компиляторами. Для каждого нового ЯВУ нужен лишь новый препроцессор. Аналогично, если создан постпроцессор для новой аппаратуры, то с ним будут работать все старые препроцессоры. Такой модульный подход упрощает создание компиляторов ЯВУ для нового компьютера.

Набор команд MI аналогичен общей промежуточной форме, применяемой в компиляторах. Компилятор ЯВУ преобразует исходный текст в форму для MI. Транслятор, расположенный уровнем ниже MI, считывает программу в этой форме, выполняет оптимизацию и генерирует инструкции IMPI или PowerPC. Транслятор очень напоминает постпроцессор компилятора.

Общая промежуточная форма для некоторых языков может как транслироваться, так и интерпретироваться. В главе 11 мы рассмотрим язык Java, использующий как раз такую форму. Промежуточная форма Java, известная как байт-код, также включена в MI.

Набор инструкций MI заменяет общую промежуточную форму не во всех компиляторах AS/400 — некоторые языки имеют собственную промежуточную форму. Ниже приводится описание внутренней структуры компиляторов языков для AS/400, и место MI в этой структуре.

Компиляторы для AS/400

Ранние компиляторы (например, RPG/400 и языка управления CL) для System/38 и AS/400 генерировали команды: MI довольно прямолинейно. Хотя они и проходили уровень ассемблера, в самом компиляторе не было общей промежуточной формы. Ее роль выполняли команды MI.

Модель программы для этих языков, включая форму программы ниже уровня MI, называется исходной моделью программ или OPM (Original Program Model). Позднее, для языков типа C/400, была добавлена расширенная модель программ или EPM (Extended Program Model). На рисунке 4.2 показан процесс генерации кода IMPI для OPM и ЕРМ. Мы представили здесь эти две модели только для демонстрации эволюции компиляторов AS/400. На RISC-системах версии 4 не используются ни компиляторы ОРМ, ни ЕРМ.

Сначала рассмотрим компилятор ОРМ. Он принимает на входе операторы ЯВУ ОРМ (вместе с не показанными на рисунке описаниями файлов) и на выходе генерирует код промежуточного представления программы IRP (Intermediate Representation of a Program). IRP, по сути, — ассемблер для команд MI. Следующий шаг — код IRP преобразуется в команды MI с помощью компонента под названием PRM (Program Resolution Monitor), который создает шаблон программы, помеченный на рисунке как шаблон программы ОРМ и содержащий команды MI и другие данные. Шаблоны используются для создания объектов MI. Транслятор, расположенный ниже уровня MI, создает по шаблону программы программный объект, содержащий команды IMPI. Содержание шаблона программы будет рассмотрено далее.

ОРМ — пример классического компилятора, генерирующего ассемблерную форму программы (IRP), после чего ассемблер (PRM) генерирует двоичную машинную программу (шаблон программы). Компиляция на AS/400 требует дополнительного шага (этапа трансляции) и поэтому может занимать больше времени, чем на некоторых других системах. Обратите внимание, что все эти этапы для пользователя AS/400 невидимы и выглядят, как одна операция.

По мере реализации на AS/400 новых языков, таких как С/400 и Pascal, потребовалось добавить расширения. Этапы компиляции для ЕРМ (расширенной версии ОРМ) также показаны на рис. 4.2. В компиляторах таких языков препроцессор и постпроцессор разделены. Общая промежуточная форма в них называется U-код. Для AS/400 был создан новый постпроцессор компиляторов CUBE-1 (Common Use Back End 1).

Рисунок 4.2 Компиляторы ОРМ и ЕРМ

Для повышения производительности модульного программирования и стимуляции его распространения на все языки, были внесены архитектурные расширения в MI и объекты, расположенные ниже. Эта модификация датирована 1993 годом и называется ILE (Integrated Language Environment). В состав ILE входят новые компиляторы ЯВУ, новый оптимизирующий транслятор (OX) и новые средства связи для создания многомодульных программ[ 35 ]. ILE изменил программирование. В отличие от ОРМ, на выходе у этого транслятора не программный объект, а модуль. Средство связывания ILE компонует эти модули в программы.

Кроме поддержки вызовов с поздней компоновкой ОРМ, в ILE есть возможность компоновки во время компиляции. Преимущество такой ранней компоновки состо-

ит в сокращении накладных расходов, связанных с внешними динамическими вызовами. Заранее скомпонованные или статические вызовы выполняются быстрее.

Прежде чем идти дальше, требуется четко оговорить, что мы понимаем под некоторыми терминами.

• Процедура — последовательность операторов, которая может быть вызвана в точке входа, возможно, с некоторыми параметрами.

• Модуль — объект, содержащий код, полученный на выходе компилятора ILE. В отличие от программы, создаваемой компилятором OPM, модуль не исполняем. Модуль может содержать одну или несколько процедур. Компоновщик ILE собирает программы и служебные программы из модулей, возможно, написанных на разных языках.

• Программа — исполняемая единица кода, состоящая из одного или нескольких модулей, которые могут быть сгенерированы компиляторами разных языков. У программы единственная точка входа, и она запускается динамическим вызовом. Входом в программу при ее создании назначается одна из процедур, и после вызова программы управление передается этой процедуре. Процедуры внутри программы запускаются статическими вызовами.

• Служебная программа — исполняемая единица кода, состоящая из одного или нескольких модулей, которые могут быть сгенерированы компиляторами разных языков. Служебная программа активизируется как единое целое, но рассматривается как набор процедур. Каждая из таких процедур может быть вызвана статическим вызовом. Таким образом, служебная программа может иметь несколько точек входа — по одной на каждую процедуру.

• Группа активизации — рабочая область памяти внутри задания, выделенного для выполнения одной или нескольких программ. Подробно мы рассмотрим группы активизации в главе 9.

Деление на программы и служебные программы связано с необходимостью поддержки двух типов статических вызовов: связь через копию (bound by copy) и связь через ссылку (bound by reference). Первые позволяют копировать в программу одновременно несколько модулей. Как мы только что говорили, сама программа вызывается динамически, но после этого вызовы процедур из всех модулей происходят статически. Так как имена процедур преобразуются в адреса во время компиляции, данный тип статического вызова внутри программы выполняется быстрее, чем динамический вызов. Недостаток связи через копирование в том, что в памяти может одновременно находиться несколько копий модуля, если он связан с несколькими программами. За все нужно платить, и здесь за быстродействие мы расплачиваемся дополнительным расходом памяти.

В случае связи через ссылку, модули находятся в служебной программе, а в программе сохраняются именные ссылки на них. При этом существует только одна копия служебной программы. При активизации программы эти ссылки разрешаются на адрес таблицы, находящейся в служебной программе и содержащей адреса вызываемых процедур. Запуск программы связан с некоторыми дополнительными накладными расходами, например, с проверкой авторизации (рассматривается в главе 7). Тем не менее, производительность собственно исполнения программы примерно соответствует связи через копию.

В обоих методах ранней компоновки используется новая команда вызов связанной процедуры CALLB (call bound procedure). Другая новая команда, вызов программы или CALLPGM (call program) поддерживает позднее связывание и заменяет команду вызова внешней процедуры ОРМ.

Структура компиляторов программной модели ILE показана на рис. 4.3.

Рисунок 4.3 Компилятор программной модели ILE

Препроцессор компилятора ILE генерирует общую промежуточную форму — W-код. Постпроцессор таких компиляторов называется CUBE-3. Цифрой 3 обозначено третье и самое последнее поколение технологии компиляторов IBM. CUBE-3 и W-код спроектированы с учетом эффективной поддержки RISC-процессоров.

Другие системы IBM, в частности RS/6000, используют те же технологии. Постпроцессор компилятора ILE генерирует непосредственно шаблон программы ILE, устраняя IRP и шаг PRM. Чтобы обеспечить необходимую оптимизацию RISC-процессоров, в MI добавлены арифметические команды и команды переходов в стиле W-кода, которые мы рассмотрим далее.

Модель ILE — единственная программная модель для RISC-процессоров — является расширением архитектуры MI. На системах IMPI программные модели ILE и ОРМ/ЕРМ сосуществуют, так что на одном и том же компьютере может использоваться и код, сгенерированный старыми компиляторами, и сами компиляторы.

Рисунок 4.4 Компиляторы ОРМ и ЕРМ на V4 RISC

Перенос программы ОРМ/ЕРМ на систему RISC вызывает ее внутреннее преобразование в программную модель ILE. На рис. 4.4 показаны шаги компиляции ОРМ или ЕРМ для системы RISC версии 4. Для использования старых компиляторов на новых RISC-моделях нужен дополнительный шаг: результат работы таких компиляторов — шаблон оригинального MI — должен быть преобразован в шаблон ILE MI. Компонент, выполняющий данное преобразование, называется Magic, (намек на то, что преобразование происходит как бы магическим образом).

Рисунок 4.4 Компиляторы ОРМ и ЕРМ на V4 RISC

Характеристики машинного интерфейса

Сравнивая MI с обычным машинным интерфейсом, мы отмечаем, что MI — интерфейс высокого уровня. Дело в том, что многие команды MI выполняют очень сложные функции. Например, не многие обычные машинные интерфейсы содержат функции вызова, поддерживающие как раннюю, так и позднюю компоновку, для них более характерны обычные команды перехода.

Чтобы лучше понять разницу, разберем команду обычного машинного интерфейса (см. рисунок 4.5). Она состоит из кода операции и одного или нескольких полей операндов. Команды могут быть арифметическими (в каждом компьютере есть команда сложения), передачи управления и манипуляции с данными. Самое важное, с какого рода операндами имеют дело эти команды.

Рисунок 4.5 Обычный машинный интерфейс

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

Мы уже говорили о недостатке такой структуры — ее существенной зависимости от аппаратной технологии. Так как команды: работают в адресном пространстве, с областями ввода/вывода и регистрами, они привязаны к этим физическим структурам. Изменение последних может потребовать изменения команд. Значит, преобразование существующих программ может вызвать существенные проблемы.

Рисунок 4.6 Машинный интерфейс AS/400

Машинный интерфейс AS/400 (см. рисунок 4.6) устроен совсем иначе. У него, как и у обычных, есть набор команд с кодами операций и операндами. Есть в нем и разные типы арифметических операций (например, команды: сложения) и операций передачи управления, работающие с традиционными операндами. Но в отличие от обычного интерфейса в нем есть команды, аналогичные промежуточному представлению, используемому в современных компиляторах ЯВУ, а также структуры данных (объекты).

Самое важное отличие не в самих командах или операциях, а в используемых ими операндах. В обычном интерфейсе есть регистры, память и непосредственные данные. На AS/400 мы по-прежнему имеем непосредственные данные, но нет ни регистров, ни памяти. Их заменяют объекты.

В MI определены объекты нескольких типов. Большинство из них — сложные структуры данных, нужные для представления информационных ресурсов. Один из самых важных типов объектов в системе — пространство (просто набор байтов, не связанный с физическим оборудованием). Многие с трудом представляют себе массу подвешенных неизвестно где байтов, им хочется обязательно связать их с аппаратурой. Но в MI понятие пространства не имеет отношения к физической памяти, он абсолютно независим от того, что находится ниже[ 36 ].

Когда программе MI требуется память, она использует пространство. На этом уровне нет понятий регистров, физической памяти и адресов памяти в традиционном смысле. Например, компилятор AS/400 должен куда-то деть созданный шаблон программы — в пространство!

Кроме пространств, существуют и другие типы объектов, которые мы обсудим далее. До сих пор мы обсуждали только системные объекты MI. Но объекты поддерживает и OS/400.

Работа с программами MI

Несколько команд MI работают с программами. Так как программа представляет собой объект, эти команды: рассматривают программу целиком. Все команды выполняют над программой только операции, имеющие смысл. Есть команда создания программы, но нет команды перемножения программ, так как первая имеет смысл, а вторая — нет. Короче, команды специфичны для объектов того типа, с которым они манипулируют. Команды применяются к объекту целиком, а не к некоторым частям данных внутри объекта. Объект нельзя использовать не по назначению, так что еще одно крупное преимущество объектной ориентации — целостность. Программы в MI играют только присущую им роль. Давайте рассмотрим, как программа создается, уничтожается и материализуется.

Создание программы

Программа создается на основе шаблона — заранее описанной структуры со всеми характеристиками определенного системного объекта MI. Шаблон формируется частью компилятора AS/400, отвечающей за генерацию кода. Все системные объекты MI образуются по шаблонам, хранящимся в пространствах MI. Так как объектам разного типа присущи разные характеристики, единого общего шаблона нет — у каждого объекта свой уникальный шаблон.

Команда создания программы «Create Program» указывает на шаблон программы. Пока мы остановимся на двух типах указателей: системном и пространственном (позже мы увидим, что есть указатели и других типов). Первый направлен на системный объект MI, второй — на байт в пространстве. Длина каждого из этих указателей 16 байт. Через указатели в MI осуществляется адресация, так что указатель в MI можно представлять себе просто как адрес.

Команда создания программы исполняется с помощью кода, лежащего ниже MI. Сначала через пространственный указатель команды «Create Program» код находит шаблон программы, над которым выполняется синтаксический контроль. Затем транслятор преобразует последовательность команд MI-шаблона программы в последовательность внутренних команд IMPI или PowerPC, которая упаковывается в системный объект MI — программу. Наконец, инициатору запроса возвращается адрес вновь созданной программы в виде системного указателя на этот объект. Если в какой-то части данной операции возникают проблемы, соответствующая диагностическая информация возвращается в виде сообщения.

Уничтожение программы

Любой объект на уровне MI, который можно создать, можно и уничтожить. Соответственно на каждую команду создания объектов MI приходится команда уничтожения. Пользователь на уровне MI устанавливает системный указатель на программу или другой объект MI и дает команду: «Уничтожить». Конечно, сделать это просто так нельзя: у пользователя должны быть соответствующие права на доступ к разным объектам.

Тему прав пользователей по отношению к объектам мы подробно обсудим в главе 7, а сейчас только упомянем, что пользователь может иметь разные уровни прав доступа к разным объектам. Чтобы уничтожать объекты, нужен самый высокий уровень. Как правило, объект может уничтожить только его владелец; но бывают ситуации, когда такие права имеют несколько пользователей. Каждому пользователю в системе соответствует специальный объект — профиль пользователя. Вместе с другими объектами профиль пользователя определяет права данного пользователя по отношению к тем или иным объектам. Когда пользователь прибегает к команде уничтожения, система сначала обращается к его профилю и выясняет, есть ли у него такое право, и лишь в случае утвердительного ответа выполняет операцию.

Материализация и адаптируемость программы

Наблюдать характеристики программы поверх MI можно лишь через шаблон программы. Шаблон — результат работы компиляторов ЯВУ. Это самый нижний уровень, на котором возможна работа с компонентами программы поверх MI. Ниже MI программа существует в виде системного объекта, и все работающие с ним команды MI воспринимают его как единое целое.

Внутри объекта находится последовательность команд IMPI или PowerPC. Объект инкапсулирован, то есть, невидим извне. Это обеспечивает независимость от технологии, однако программа не имеет законченной формы, так как последовательность ее команд невидима.

Однако, если прикладному или системному ПО необходим доступ к характеристикам программы, команда MI, позволяет эту программу материализовать. Команда материализации указывает на инкапсулированный программный объект, по которому воссоздается шаблон программы. Материализация — операция, противоположная инкапсуляции.

Технологию материализации не всем просто понять. Честно говоря, обратная компиляция (восстановление исходного текста программы при наличии ее только в откомпилированном виде) не слишком хорошо разработана и многолетние исследования в этой области идут пока без особого успеха.

Как же решает эту задачу AS/400? Да просто жульничает: она не выполняет де-компиляции последовательности команд IMPI или PowerPC. Вместо этого копия шаблона программы сохраняется вместе с объектом. Когда выполняется команда MI материализующая программу, в ответ возвращается объект шаблона программы.

Хранение шаблона программы в качестве системного объекта MI и придает System/38 и AS/400 возможности, отсутствующие в других системах. Это позволяет изменять набор команд, не влияя на приложения заказчиков. Изменения вносятся в новую версию транслятора, а затем все программы ретранслируются из своих шаблонов. Наконец, новые последовательности команд снова инкапсулируются в объекты. Все это происходит ниже MI и без участия пользователя.

Чтобы Вы смогли лучше «почувствовать разницу», обратимся к классическому примеру внедрения System/38 Model 7. System/38 появилась как абсолютно новая система с абсолютно новым набором команд, новыми приложениями и новой ОС. Но как использовать эти команды:, никто точно не знал. Как правило, для того, чтобы достичь максимальной производительности системы, оптимизируют аппаратную реализацию наиболее часто встречающихся последовательностей команд с целью достичь их как можно более быстрого выполнения.

Первоначально набор команд IMPI имел только 8-битные коды операций, то есть команд не могло быть более 256 (28 = 25 6). Когда начали писать приложения для System/38, то обнаружилось, что нужны новые функции. В ответ мы изобретали новые команды (своего рода болезнь!) и очень скоро вышли за эти пределы.

Вполне естественно стремление сохранить набор операций небольшим, а следовательно, контролируемым и не избыточным. Но не менее законно желание упростить сложные задачи. Как увязать эти противоречия? Хорошо, если б существовал научный метод создания наборов команд, но, увы! Это скорее искусство, чем наука. Через пару лет мы пришли, как нам казалось, к оптимальному набору команд IMPI. И чтобы добавить эти новые команды, решили ввести в формат команд IMPI расширения кода операции.

К тому времени мы уже знали, как работать с существующими командами IMPI и как повысить производительность путем перевода наиболее часто используемых команд в другие, более быстрые форматы. Изменение кодов операций означает, что команда, на предыдущей версии оборудования вызывавшая, скажем, загрузку, на новой версии служит для передачи управления. В любой «нормальной» системе такая замена привела бы к хаосу, но не в System/38 — ведь она не зависит от технологии.

При модернизации оборудования системы устанавливалась и новая версия транслятора. У каждой программы в системе был свой заголовок объекта, который, кроме всего прочего, показывал, какой уровень транслятора использовался для создания программы. При первом исполнении программы система проверяла заголовок и при обнаружении старой версии обрабатывала связанный с объектом шаблон программы новым транслятором, сохраняя новый код IMPI в объекте. После этого программа выполнялась. Ретрансляция производится лишь однажды — при следующих вызовах программы используется новый код.

Это работало блестяще, но... начались претензии заказчиков: «Я только что °—° установил систему, и мне кажется, что прикладные программы стали работать медленнее». Это и понятно: ретрансляция впервые запущенного приложения приводила к замедлению работы. Как Вы думаете, что мы отвечали? Конечно же — «Попробуйте еще раз». Тот же метод скрытой ретрансляции программ применялся при переходе на RISC-процессоры. Разница была лишь в том, что заказчиков заранее предупреждали, что приложения будут работать, только если не удалена адаптируемость. Что же изменилось со времен System/38?

AS/400 должна была привлечь и пользователей System/36, и System/38. Между тем вторые привыкли к большим объемам памяти и жестких дисков, так же как и пользователи System/36 — обходиться малым. Поэтому размеры новых программ последних пугали, и казались им чересчур большими.

Программы для AS/400 действительно впечатляли — ведь каждая хранилась в двух копиях: в инкапсулированной форме и в форме шаблона. Для экономии пространства на диске заказчики могли удалить шаблоны. Это называлось удалением адаптируемости программы (Delete Program Observability), так как после программу уже нельзя было материализовать.

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

Внутри шаблона программы

Чтобы выяснить, что там происходит, возьмем в качестве примера шаблон программы ОРМ, хотя он и не поддерживается на RISC-системах. Я выбрал ОРМ по двум причинам. Во-первых, это дает возможность рассмотреть еще несколько интересных концепций, лежащих в основе оригинального набора команд MI. Во-вторых, некоторые детали шаблона программы ILE не опубликованы. И поэтому прежде чем заняться шаблоном программы ОРМ, рассмотрим те изменения, которые были внесены в программную модель ILE.

При создании компиляторов для программной модели ILE, в MI были добавлены новые команды. Некоторые из них имеют структуру близкую к W-коду, используемому компиляторами ILE, однако не совпадают с его командами в точности. Права на W-код принадлежат лаборатории IBM в Торонто (Toronto), Канада, которая пока не желает лицензировать интерфейс W-кода кому-либо за пределами IBM, опасаясь, что другие смогут разрабатывать и продавать компиляторы для AS/400. Мы решили определить команды! MI, которые похожи, но не в точности совпадают с W-кодом, чтобы не связываться с Торонто, если там когда-либо будет принято решение открыть этот интерфейс другим фирмам.

Наилучший целевой компьютер для компиляторов ILE — стековая машина, поэтому MI был расширен для поддержки стеков. Стек — набор данных, хранящихся последовательно. Первый помещенный в стек элемент называется его дном, последний — вершиной. Для работы со стеком используются команды без явного указания операндов, которые определяются путем извлечения из стека двух верхних элементов. В противоположность этому, команды ОРМ имеют два операнда, заданных непосредственно в команде. Для стековой машины операция задается после операндов. Такая форма записи называется постфиксной или обратной польской в честь математика Лукашевича (J. Lukasiewicz), исследовавшего ее свойства[ 37 ].

Интересно, что архитектура, разработанная в 1972 году, имела аналогичную поддержку стека. В то время многие полагали, что блочно-структурированные языки, такие как PL/1, станут очень популярными. Но они так и не вытеснили RPG и Cobol, так что стек был временно отвергнут. Теперь, с появлением таких языков как С, мы снова вернулись к нему.

Рисунок 4.7 Команды и ODT

Шаблон программы состоит из нескольких частей. Шаблон программы ОРМ содержит заголовок, последовательность команд MI, пользовательские данные и структуру под названием таблица определения объектов ODT (object definition table). Команды и ODT представлены на рисунке 4.7. Последовательность команд на рисунке содержит пример команды MI. Использована классическая команда OPM с тремя операндами —арифметическое сложение. Она состоит из кода операции, за которым следуют три значения, используемые для поиска трех операндов. Каждое из них является индексом в ODT. Показанная на рисунке команда запрашивает сложение операнда 6 с операндом 2 и помещение суммы в операнд 3.

ODT состоит из двух компонентов. Первая — ODV (ODT Direction Vector) — содержит по одному элементу для каждого операнда программы. Все элементы имеют одинаковую длину, так что значение из последовательности команд может использоваться как индекс в ODV. Элементы ODV описывают операнды. В нашем примере, операнды 6 и 3 — это двоичные числа длиной 2 байта, а операнд 2 — константа. Константы и другие типы операндов могут иметь переменную длину, что задает необходимость второго компонента ODT. OES (ODT Entry String) содержит операнды переменной длины, не умещающиеся в ODV. Содержимое поля ODV указывает на начало цепочки в OES. В нашем примере операнд 2 представляет собой константу 1253.

Пример иллюстрирует несколько характеристик команд MI модели ОРМ. Во-первых — это команда арифметического сложения. Это не команда двоичного или десятичного сложения, или сложения с плавающей запятой; она универсальна. Формат операндов команды определяется в ODT. В нашем примере используются двоичные целые операнды, но они могли бы иметь любой числовой формат. За генерацию необходимых преобразований отвечает транслятор.

Во-вторых, из примера видно, что ОРМ MI — неисполняемый интерфейс. Обратите внимание, что ни с операндом 3, ни с операндом 6 не связаны значения. Элемент ODV эквивалентен объявлению переменной. Память для переменной не выделена, так что транслятор обязан завершить компиляцию и назначить переменным регистры или области памяти.

И, наконец, в примере показана обычная вычислительная команда. Команда, работающая с объектом, имела бы аналогичный формат, но в ODT было бы указано, как найти объект (детали адресации объектов будут рассмотрены в главе 5).

Форматы команд MI

Рисунок 4.8 Формат команд MI

На рисунке 4.8 показан формат команд ОРМ MI в потоке команд. Команда состоит из кода операции, необязательного расширения кода операции, а также нуля или более операндов. MI проектировался в расчете на последующие расширения, так что формат команды допускает увеличение числа команд и операндов. Код операции и его расширение представляют собой 16-разрядные поля. Поле операнда, используемое как индекс в ODV, первоначально на System/38 имело длину 16 бит, но затем было расширено до 24 бит. Это означает, что в программе может быть до 16 миллионов (224) разных операндов, и эта цифра может быть увеличена.

Экономия памяти не была слишком важна для шаблона программы. Например, команда арифметического сложения заняла бы 2 байта для кода операции, 2 байта — для расширения кода операции и 9 байтов — для операндов. Получается 13 байтов, и мы еще не учли пространство для операндов в ODT. Не удивительно, что пользователи System/36 были недовольны объемом дискового пространства, занимаемого программами.

Код операции MI

В таблице 4.14 показано назначение битов кода операции MI. Бит 3 задает вычислительный или невычислительный формат команды. Во втором случае функция, которая должна быть выполнена, закодирована в битах 5-15 кода операции. Функция, выполняемая вычислительной командой, задается битами 8-15. В этом случае, как в примере с арифметическим сложением, биты 5-7 содержат дополнительную информацию о команде.

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

Бит 7 указывает на сокращенную форму команды, что также имеет смысл только для вычислительных команд. В нашем примере арифметического сложения участвуют три операнда. Два из них складываются, и результат помещается в третий, то есть два первых операнда не изменяются. Сокращенная команда также складывает первые два операнда, но результат помещается в первый операнд. Таким образом, сокращенная команда использует формат только с двумя операндами.

Таблица 4.1 Назначение битов кода операции

Наконец, в вычислительном формате имеются два бита, описывающих расширение кода операции. Биты 4 и 5 определяют наличие расширения и если таковое присутствует — способ его использования. Это требует более подробного объяснения.

Расширение кода операции

Расширение кода операции MI занимает следующие 16 бит команды и имеет две формы: опция перехода и опция индикации. Наличие расширения задается установкой бита 4, а в положительном случае разряд 5 выбирает опцию перехода или индикации.

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

Рассмотрим первое 4-разрядное поле расширения. Значение 1 (двоичное 0001) в этом поле означает переход в том случае, если в результате вычисления получено положительное число. Значение 2 (двоичное 0010) задает переход при отрицательном значении результата. Если же поле имеет значение 4 (двоичное 0100), то переход выполняется при результате равном 0. Имеются также значения для перехода при ненулевом, неположительном, неотрицательном и не ненулевом результате. Кроме того, та же самая комбинация битов может иметь разный смысл для разных типов команд. Например, команда сравнения интерпретирует биты иначе, чем команда сложения.

Если условие перехода, заданное первым 4-разрядным полем выполнено, то цель перехода может быть найдена за последним операндом команды. Если условие перехода не выполнено, то будет исполняться следующая команда по порядку. Такие возможности команд приводят к увеличению их длины.

Так как каждое из четырех 4-разрядных полей расширения используется для задания условия перехода, то каждая вычислительная команда может содержать до

четырех условий и до четырех целей перехода. Если нужно менее четырех условий, то значение 0 задает отсутствие перехода.

Возможность MI выполнять переход в четыре точки после каждой вычислительной команды обеспечивает набору команд большую мощность за счет их удлинения. В примере с арифметическим сложением — до четырех целей перехода, что увеличивает длину команды еще на 12 байтов. Команда может занимать в памяти до 25 байтов. Это не создает проблем во время выполнения, так как команды: MI не исполняются непосредственно. Однако размер программы увеличивается.

Опция индикатора работает аналогично опции перехода. Расширение содержит те же четыре 4-разрядных поля с теми же возможными значениями. Отличие в том, что вместо перехода при выполнении условия устанавливается индикатор. Индикатор представляет собой переменную в памяти, содержащую десятичные значения 1 или 0. Если в процессе выполнения вычислительной команды условие, заданное 4-разрядным полем, выполнено, то индикатор устанавливается в значение 1, в противном случае —в значение 0. Как и в случае перехода, в команде может быть задано до четырех индикаторов, которые указываются следом за операндами.

Многие читатели узнали в этом описании индикаторы RPG. Возможность установить индикатор и затем, в зависимости от его значения, выполнить некоторое действие восходит к оборудованию обработки единичных записей. Индикаторы RPG поддерживаются набором команд MI непосредственно[ 38 ]. На первый взгляд, эта возможность кажется устаревшей. Однако многие самые современные RISC-процессоры используют прием записи в регистр значения 0 или 1 для индикации результата вычисления. То есть, индикаторы живы и в добром здравии.

Примеры команд MI

Рисунок 4.9а Команда арифметического сложения (ADDN)

На рисунках 4.9а, 4.9б и 4.9в показаны форматы трех команд ОРМ MI. Команда арифметического сложения ADDN имеет шестнадцатиричный[ 39 ] код операции 1043, а также три операнда. Это вычислительная команда, и функция сложения в ней имеет код 43.

Рисунок 4.9b Команда перехода (B)

Рисунок 4.9c Копирование байтов с выравниванием влево и заполнителем (CPYBLAP)

В таблице 4.27 приведены 11 других форм ADDN. Различные варианты команды получаются путем комбинации опций сокращенной команды, округления, индикатора и перехода. Обратите внимание, что кодом функции по-прежнему остается 43.

ADDNS	1143	Короткая
ADDNR	1243	С округлением
ADDNSR	1243	Короткая с округлением
ADDNI	1843	Индикаторная
ADDNIS	1943	Индикаторная короткая
ADDNIR	1A43	Индикаторная с округлением
ADDNISR	1B43	Идикаторная короткая с округлением
ADDNB	1C43	С переходом
ADDNBS	1D43	Короткая с переходом
ADDNBR	1E43	С оКороткая с округлением и с пере-
ходом

Таблица 4.2 Формы команды арифметического сложения

Команда перехода (рисунок 4.9б) имеет только один операнд — точку перехода и задает безусловный переход. В MI нет отдельной команды условного перехода, а все условные ветвления выполняются в результате некой вычислительной команды. Так как переход является не вычисляемой командой, у нее нет разных форм, как у ADDN.

Третья команда (рисунок 4.9) имеет чудесное, хоть и немного длинное, имя «CPYBLAP» («Copy Bytes Left-Adjusted with Pad»). Она позволяет скопировать строку байтов из одного поля в другое. Байты выравниваются по левому краю принимающего поля, и если исходное поле короче принимающего, то оставшиеся байты будут заполнены заданным значением. Понятно, что это лишь одна из многих команд копирования в MI. В большинстве коммерческих приложений копирование используется очень интенсивно. Возможно, читатель узнал в «CPYBLAP» аналог оператору «Move» в языке Cobol или «MOVEL» с P в колонке полувыравнивания из RPG.

Мы рассмотрели лишь три команды MI (а есть еще сотни и сотни других) и только команды: MI (вычислительные и перехода) модели OPM. Как уже упоминалось, существуют также вычислительные команды и команды перехода для поддержки ILE. В следующих главах мы поговорим о командах для работы с объектами.

Выводы

Независимость от технологии, обеспечиваемая MI, чрезвычайно важна, так как позволяет избегать изменений в пользовательских приложениях и в OS/400. Все возможности нового оборудования могут быть задействованы сразу же после его установки.

Но это не единственное преимущество MI! Вычислительная среда со временем меняется: наглядные примеры — приложения клиент/сервер и концепция сетевых вычислений. Если бы AS/400, первоначально предназначенная для интерактивной работы, не смогла приспособиться к роли сервера, она бы уже давно устарела.

MI — мощнейший интерфейс не только в силу своей независимости от технологии, но и благодаря возможностям расширения. Новые инструкции и функции присутствуют почти в каждой версии системы. Интерфейс MI ориентирован на приложения, так как поддерживает необходимые для этого API, и по мере появления новых приложений добавить новые API не составит проблемы. Расширяемость архитектуры MI делает этот интерфейс чрезвычайно долговечным.

Глава 5

Объекты

Сетевые вычисления и Интернет сделали тему объектных технологий бестселлером компьютерных новостей. Распространение таких языков программирования, как Java и С++, заставляет разработчиков приложений изменить свое отношение к традициям и признать преимущества новых объектно-ориентированных языков.

Подобно другим технологиям, которые мы считаем новыми, объекты используются в программировании уже более 30 лет. Впервые они появились в конце 60-х годов в языках типа Simula 67, применявшихся для программ моделирования. Современные языки программирования, такие как Java, C+ + и Smalltalk — прямые потомки Simula 67. Программы моделирования имитируют поведение объектов реального мира. Аналогично, прикладные программы для бизнеса, содержащие объекты и операции над ними, моделируют реальные деловые отношения.

ОС работают с аппаратными и программными объектами, такими как устройства ввода-вывода и программы. Использование объектов в ОС выглядит совершенно естественным. О создании объектно-ориентированной ОС говорят многие фирмы, такие как Microsoft, Apple, Novell/USL (UNIX Systems Laboratory) и Sun Microsystems, однако, лишь немногие из них смогли реализовать свои планы. Одна из таких фирм — Next, уже поставляющая на рынок объектно-ориентированную ОС под названием NextStep.

Есть, конечно, и другая объектно-ориентированная ОС. С момента появления System/38 мы строим ОС (CPF и OS/400) по объектно-ориентированной модели[ 40 ]. Более того, мы не остановились на этом, но сделали объекты фундаментальной частью архитектуры машины. Как уже отмечалось в главе 4, MI состоит из двух частей: команд и объектов. В этой главе мы рассмотрим использование объектов в AS/400.

Иногда говорят, что AS/400 это не объектно-ориентированная система, а система на основе объектов (object-based). Различие этих двух терминов имеет смысл при обсуждении языков программирования. Например, есть языки на основе объектов, такие как Ada, и объектно-ориентированные языки, такие как Smalltalk-80. Гради Буч (Grady Booch) определил различия между этими двумя типами языков. По Бучу, в языке на основе объектов отсутствует наследование[ 41 ]. Как уже вкратце упоминалось в главе 3, наследование определяет иерархию классов, где подкласс заимствует структуру или поведение одного или нескольких базовых классов. Наследование позволяет создавать новые типы объектов. Так как объекты AS/400 ничего не наследуют от других объектов, и прикладные программисты, пишущие приложения для этой системы, не могут создавать новые типы объектов, то вероятно, правильнее называть AS/ 400 системой на основе объектов. Но какое бы имя мы не выбрали, важно то, что AS/

400 не просто использует или включает объекты, — они являются фундаментальной частью ее архитектуры.

В упрощенном виде объект — это просто контейнер, внутри которого находятся пользовательские и системные структуры данных. Объект инкапсулирован, что означает (как мы условились ранее) невозможность заглянуть внутрь него. Система, построенная на основе объектной модели независима от аппаратуры. Первопричиной использования объектов в System/38 было желание инкапсулировать детали, чтобы позже их можно было изменять без влияния на прикладные программы.

Еще одно достоинство объектов — целостность. Оригинальная System/3 была байтовой машиной (то есть все в ней располагалось на границе байта), а ее команды содержали однобайтовый код операции. Они занимали несколько последовательных байтов памяти, но никакого обязательного выравнивания команд не было. Более того, все разряды кода были задействованы для задания типа операции и местоположения операндов. Практически любая комбинация разрядов в байте могла быть интерпретирована как допустимый код операции System/3.

Это вызывало проблему, если в программе непреднамеренно происходил переход в область данных: процессор мог продолжать выбирать байты данных и интерпретировать их как команды. Такая программа могла исполняться долгое время, сея хаос внутри системы. Ликвидировать последствия таких ошибок было весьма сложно.

В этом плане System/3, ничем не отличалась от большинства других вычислительных систем того времени. Например, в обычной системе цепочка байтов может быть интерпретирована, практически, как угодно. Можно взять байты из одной части программы и перемножить их с байтами из другой ее части. Процессор «не волнует», имеет ли смысл такая операция. Он работает с байтами, а не с тем, что они представляют.

Итак, мы были очень обеспокоены проблемами целостности, и сделали все, чтобы таковых не возникало в AS/400. Команды в этой системе могут работать только с теми объектами, для которых предназначены. Некоторые универсальные команды, такие как «Создать объект», применимы ко всем объектам, другие — работают только с объектами определенных типов. Таким образом, в AS/400 нельзя использовать объект не по назначению, как в обычной системе. В результате целостность значительно повышается.

На эту проблему можно взглянуть и с другой стороны. В большинстве ОС, все, что находится в постоянной памяти, считается файлом (в MS-DOS или MVS файлом называют набор данных). Файлы могут иметь различное назначение, но такая классификация определяется лишь по соглашению. Вы можете читать объект-программу так, как если бы это был файл. В OS/400 это невозможно (как и создать вирус, по крайней мере, в слое над MI), так как термин «файл» применим лишь к небольшому числу типов объектов, и программа определенно файлом не является. Кстати, с этим связаны некоторые неудобства, присутствовавшие в System/38, где значительная часть информации об объектах была недоступна программам. COMMON (группа пользователей AS/400) многократно просила включить во все команды отображения, такие как, например, «DSPOUTQ» («Display Output Queue»), «DSPJOBQ» («Display Job Queue»), опцию генерации выходного файла, чтобы информация, хранящаяся внутри объектов, могла быть считана программно. В конце концов, мы добавили такую возможность в некоторые команды:, которые первоначально ей не обладали (а в «DSPOUTQ» и «DSPJOBQ» ее нет и сейчас). Но исчерпывающим ответом на эти запросы было создание API, позволяющих поместить информацию об объектах и системе в объект, известный как пользовательское пространство. Этот объект программы могут читать быстрее, чем файлы базы данных.

Имена объектов

В System/38 объекты были как в ОС, так и в MI. Определением этих объектов и выбором имен для них занимались две разные группы. Одна разрабатывала объекты CPF, (которая в AS/400 была переименована в OS/400[ 42 ]), другая — разрабатывала набор команд и системные объекты MI.

Хорошо, что иногда между объектом OS/400 и объектом MI соотношение один к одному, тогда это тот же самый объект. Все усложняется, когда это разные объекты. Все объекты OS/400 состоят из одного или нескольких системных объектов MI. Другими словами, типы объектов OS/400 и типы системных объектов MI соотносятся как один к одному или как один ко многим, но никогда как многие к одному или многие ко многим.

Пример, иллюстрирующий это положение, мы рассмотрим в следующем разделе. А теперь, прежде чем идти дальше, я должен внести ясность еще в одну область.

Иногда, объекты OS/400 и системные объекты MI, даже при соотношении между ними один к одному, могут называться по-разному. Например, в OS/400 есть объект «библиотека», в MI эквивалентный объект называется «контекст». Как это могло получиться? Ответ восходит ко времени создания System/38 двумя разными группами проектировщиков с разными подходами к выбору названий.

Один подход таков: коль Вы создаете новую систему — то все надо переименовать, и пусть пользователи, видя новые названия вдумаются в новую структуру. По этой логике, если Вы собираетесь реализовать библиотеку и назвали ее библиотекой, то кто-нибудь обязательно скажет: «Я знаю, что такое библиотека; я уже работал с системой, где есть библиотеки». Между тем, библиотека в другой системе может полностью отличаться от Вашей. Если же дать библиотеке другое название, например «контекст», то никто не сможет априори строить о ней какие-либо предположения. Данный подход к именам защищал Гленн Хенри — менеджер программирования System/38 и, следуя подобным взглядам, группа, разрабатывавшая системные объекты MI, породила некоторые весьма странные названия.

Названия же для объектов ОС выбирала другая группа, предпочитавшая подход Томаса Эдисона (Thomas Edison): лучше даже не вполне подходящее, но уже знакомое покупателям имя. Когда Эдисон продвигал идеи использования электроэнергии, он решил выбирать названия, знакомые каждому, использующему природный газ. Он говорил, что к дому подводятся электрические магистрали (main), подобно газовым или водопроводным магистралям, хотя main — это труба или канал, а электроны, обычно, попадают в дом не по трубе. Он также называл нагревательный элемент кухонной плиты электрической горелкой, чтобы электрическая плита казалась чем-то знакомым людям, имевшим дело с газовыми горелками (скажем честно — электричество в нагревающем элементе не «горит»). Наша группа разработчиков ОС понравилась бы Эдисону.

Объекты OS/400 и системные объекты MI

Несколько типов объектов имеются и в OS/400, и в MI. Типы объектов OS/400 перечислены в таблице 5.1. Для сравнения, в таблице 5.2 приведены системные объекты MI. Помните, что в каждой новой версии AS/400 добавляются новые функции и даже новые объекты. Списки объектов таблицах 5.1 и 5.2 достаточно полны для нашего обсуждения в этой и следующей главе, но включить в них все типы объектов невозможно.4

Графический набор символов	Служебная программа
Документ	Описание сетевого интерфейса
Идеографическая таблица символов	Описание сессии
Идеографическая таблица сортировки Описание подсистемы
Идеографический словарь	Словарь правописания
Индекс поиска информации	Таблица
Класс	Библиотека
Класс описания сервиса	Описание линии
Команда	Определение меню
Область данных	Определение группы панели
Описание задания	Пользовательский индекс
Описание контроллера	Очередь сообщений
Описание редактирования	Программа
Описание устройства	Модуль
Очередь данных	Определение продукта
Очередь заданий	Пользовательский профиль
Папка	Справочная таблица трансляции кода
Словарь данных	Описание режима
Список документов	Выходная очередь
Список конфигурации	Файл сообщения
Список прав	Журнал
Таблица управления формами	Описание машины S/36
Файл	Определение запроса
Формат диаграммы	Приемник журнала

Таблица 5.1. Объекты OS/400

лок транзакции	Описатель режима
Группа доступа	Индекс
Индекс пространства данных	Очередь
Класс описания сервиса	Описание логического устройства
Контекст	Модуль
Курсор	Пространство управления процессом
Описание контроллера	Описатель сети
Пространство дампа	Профиль пользователя
Пространство данных	Программа (3 подтипа)
Пространство цепочки байтов	Пространство журнала
Словарь	Пространство
Список прав	Порт журнала

Таблица 5.2. Системные объекты MI

Некоторые объекты OS/400 из таблицы 5.1 полностью соответствуют системным объектам MI из таблицы 5.2, при этом имена объекта в двух разных наборах могут совпадать, а могут и не совпадать. Пример совпадения имен — «программа», несовпадения — «библиотека» и «контекст».

Рисунок 5.1 Объекты файла базы данных OS/400

На рисунке можно видеть набор отдельных компонентов. Один из системных объектов MI — область данных. Она используется базой данных для хранения физических данных вместе с определением полей записей. Еще один системный объект — индекс области данных — содержит описание того, как осуществлять доступ к этим данным. В следующей главе мы увидим, как индекс области данных обеспечивает логическое представление физических данных. Третий объект — курсор, осуществляющий фактический доступ к записям в области данных и использующий индекс области данных для формирования логического представления. Курсор предоставляет управляющие структуры для доступа к данным в области данных, а также содержит пользовательские буферы. Четвертый объект — пространство, в которое помещается результат опе-

Другие объекты OS/400 относятся к системным объектам MI как один ко многим. Посмотрите на пример на рисунке 5.1: здесь файл базы данных OS/400 состоит из пяти системных объектов MI, и ему соответствуют четыре разных типа системных объектов MI (в нашем примере два объекта-пространства). Фактически, файл могут составлять намного больше объектов. Для каждого из них существует курсор, и даже однокомпонентный файл объединения (join file) может владеть или ссылаться на 32 индекса области данных. База данных, а также связи между разными системными объектами MI будут рассмотрены в следующей главе.

рации над базой данных (по сути дела, это буфер ввода-вывода). Последний, показанный в примере объект, который также является пространством, содержит описание файла. Единственная его функция — поиск других объектов.

Поиск объектов

Найти объект в базе данных оригинальной System/38 было очень легко, так как все они были поименованы: Вы просто отыскивали нужное имя в библиотеке. Библиотека давала возможность организации объектов в группы и обеспечивала их поименный поиск. Эта структура была перенесена и в AS/400.

Библиотеки

В OS/400 библиотека — объект, который используется для поиска других объектов в базе данных. В отличие от многоуровневой иерархии каталогов в ОС ПК и Unix, библиотека OS/400 имеет одноуровневую иерархию. Для иллюстрации рассмотрим структуру имен объектов OS/400.

Чтобы найти объект OS/400 требуется знать имена библиотеки и объекта (то есть, путь «Библиотека/Объект»), а также его тип (одно и то же имя могут иметь несколько объектов, но все они — объекты разного типа). Другими словами, в библиотеке может содержаться программа SAM и пространство данных SAM, но двух программ с именами SAM быть не может. Кроме того, каждый объект находится в одной и только в одной библиотеке.

Библиотека не может ссылаться на другие библиотеки, иначе была бы нарушена одноуровневая иерархия «Библиотека/Объект». Из этого правила есть лишь одно исключение — специальная библиотека с именем QSYS, в которой, и только в которой, находятся некоторые специальные объекты OS/400 например, профили пользователей, определяющие права последних, и объекты конфигурации ввода-вывода, используемые для выполнения соответствующих операций. Подробно эти объекты рассматриваются в последующих главах.

Рисунок 5.2 Структура библиотеки OS/400

Структура библиотеки OS/400 показана на рисунке 5.2. В данном примере QSYS содержит профиль пользователя (JOHN), библиотеку (LIB1) и описание устройства (DEVD1). Библиотека LIB1 содержит файл базы данных (DB), очередь данных (DQ) и выходную очередь (OQ).

Позже мы увидим, что с каждым заданием в системе связан список библиотек. Этот список указывает системе, где следует искать объект, а также задает порядок поиска в библиотеках.

Разделяемые папки

Разделяемые папки были введены в AS/400, главным образом, для поддержки функций Office[ 43 ]. Эту идею мы позаимствовали из System/36, которая была отличной офисной системой. Для поддержки функций Office в AS/400 были добавлены объекты-папки. Интегрированная поддержка обеспечивает систему хранения всех объектов Office, содержащих необходимые данные. Среди традиционных элементов, которые могут храниться там — почта, документы, программы и файлы.

Библиотечный способ хранения документов дает пользователям возможность рассматривать эту систему как электронную картотеку, содержащую папки. Средства управления позволяют организовывать объекты, помещая их в папки. Папки могут содержать другие папки и поддерживают интерактивный поиск.

Разделяемые папки и в PC Support[ 44 ] на System/36, и в AS/400 помогают обеспечить эффективность офисного использования ПК. В дополнение к упомянутым традиционным элементам Office, в разделяемых папках могут храниться электронные таблицы, диаграммы, рисунки, а также программы и файлы ПК.

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

IBM несколько раз модифицировала PC Support, но он быстро «старел» и не соответствовал потребностям новых клиент/серверных приложений. Кроме того, PC Support поддерживал не все ОС ПК, нужные заказчикам. Хотя он и позволял использовать DOS, DOS с расширенной памятью и OS/2, но (что важно!) не мог поддерживать Microsoft Windows.

PC Support требовал радикальной замены, и IBM предложила своим заказчикам совершенно новый продукт. Client Access for OS/400 обеспечивает мощную платформу для распределенных клиент/серверных вычислений. Для привлечения новых заказчиков потребовалось также внести изменения и в файловую систему AS/400. Библиотеки для обслуживания базы данных и папки для Office и файлов ПК в целом справлялись с задачей, но им не помешали бы дополнительные возможности. В результате, была создана новая файловая система.

Интегрированная файловая система

Что если объединить в одну структуру файловую систему ПК, файловую систему Unix, а также библиотечную систему и разделяемые папки OS/400? Тогда приложение, написанное для использования файловой системы ПК или Unix, могло бы напрямую обращаться к данным, хранящимся на AS/400.

Такая интегрированная файловая система появилась в V3R1 и была названа интегрированной файловой системой IFS (integrated file system). Она объединяет все файловые системы на AS/400 общим интерфейсом и общим набором правил. Более того, любой пользователь Client Access, предпочитающий новейшие версии Windows или OS/2, может на своей рабочей станции в графическом режиме работать с библиотеками, папками и всеми новыми файловыми системами.

Первой и основной проблемой было — определить конструкцию такой файловой системы. Ведь ее отдельные части не предназначались для функционирования в единой структуре. Решение оказалось проще, чем опасались сначала.

Посмотрите еще раз на рисунок 5.2 и обратите внимание на то, что структура библиотеки OS/400 — это, по сути, подмножество структуры, используемой в ОС ПК, таких как DOS и OS/2. Пусть в мире ПК используются другие названия, но структура-то та же! ОС ПК имеют дело с файлами, а не с объектами. Библиотека там называется каталогом, внутри которого хранятся файлы. В отличие от библиотечной структуры OS/400, в каталогах ПК могут находиться другие каталоги, обычно называемые подкаталогами. Таким образом, имена файлов ПК имеют многоуровневую иерархию, в противоположность одноуровневой структуре библиотек OS/400. Имя файла ПК может иметь вид КАТ1\КАТ2\...\КАТп\ИМЯФАЙЛА. За исключением обратной косой черты (\), это — надмножество структуры имен библиотеки OS/400.

Файловая структура Unix — также надмножество библиотечной структуры OS/400. Вспомните, что объект OS/400 может находиться только в одной библиотеке, иначе говоря, к любому объекту OS/400 имеется единственный путь. Файловая система Unix поддерживает наличие множественных путей к одному и тому же объекту.

Для объединения всех этих файловых систем мы решили взять единый корень из ПК-подобной файловой системы и поместить в него все остальные. На рисунке 5.3 показано, как видится вся AS/400 и ее файловые системы клиенту Windows. AS/400 представлена как один диск, на котором находятся каталоги в стиле ПК, каталоги в стиле Unix, библиотеки OS/400 (QSYS.LIB), разделяемые папки OS/400 (QDLS) и еще несколько файловых систем поддержки новых приложений. В число последних входят: система, полностью совместимая с POSIX (QOpenSys); файловая система для пользователей LANServer (QLANSrv); файловая система для Novell Netware (QNETWARE); Network File System (QNFS) фирмы Sun Microsystems. Поддерживаются и другие файловые системы, а в будущем, по мере того как все больше приложений и их файловых систем будут использовать AS/400, добавятся новые.

Соглашение об именах в IFS основано на стандарте ПК. Имя имеет вид КАТ1\КАТ2\...\КАТп\ИМЯФАЙЛА. К радости тех, кто не может запомнить, когда использовать прямую (/), а когда обратную (\) косую черту, новое соглашение допускает обе. Вы даже можете использовать разные разделители в одном и том же имени.

В соответствии со стандартом POSIX, длина имен файлов и каталогов увеличена. На AS/400 имена в каталогах IFS хранятся в формате Unicode, который, будучи международным стандартом, поддерживает использование разных языков, включая двухбайтовые наборы символов, используемые в ряде стран. Все RISC-системы теперь позволяют хранить информацию в базе данных в формате Unicode.

IFS дает возможность пользователю рассматривать файл, хранящийся на AS/400, как расширение его собственной файловой системы. Пользователи Unix считают, что они имеют дело с файловой системой Unix, а пользователи ПК (см. рисунок 5.3) — что это файлы ПК. К тому же, если оба пользователя могут работать с одними и теми же данными, отпадает необходимость копирования этих данных. Те, кто привык к ПК или к AS/400 продолжают использовать QDLS и QSYS.LIB соответственно, а новые пользователи могут работать со своими приложениями с помощью любой из поддерживаемых файловых систем. Пользователям ПК и Unix даже не требуется изучать CL — язык команд AS/400. Они могут применять любые команды: и утилиты для DOS, Windows или Unix.

Рисунок 5.3 Интегрированная файловая система с точки зрения Windows-клиента

Нельзя забывать, что главная задача IFS — обеспечение доступа к данным. Поэтому либо формат данных должен быть изначально совместим с приложением, которое их запрашивает, либо данные должны быть преобразованы соответствующим образом. OS/400 поддерживает большинство таких преобразований, например, между кодировкой EBCDIC, (Extended Binary Coded Decimal Interchange Code) используемой «родными» приложениями AS/400, и ASCII (American Standard Code for Information Interchange), используемой ПК.

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

Доступ к объектам

Недостаточно просто найти объект. Чтобы получить к нему доступ или модифицировать объект, пользовательской или системной программе необходимы некоторые средства доступа. Для системных объектов эти средства находятся на уровне MI.

OS/400 отвечает за управление своими объектами, каждый из которых состоит из системных объектов, отслеживая последние. Компонент управления объектами в SLIC работает с системными объектами и ничего не «знает» об объектах OS/400. И в этом случае разработчики AS/400 старались поддержать независимость между двумя частями ОС, выше и ниже MI. Единственной плоскостью соприкосновения между ними является MI, и именно здесь обеспечиваться доступ к объектам.

Доступ к системному объекту осуществляется посредством системного указателя, который, занимая 16 байтов памяти, содержит адрес системного объекта, а также информацию о его типе. Более подробно формат системного указателя рассматривается в главе 8.

Адресация на базе возможностей

Системный указатель может также содержать сведения о типе операций, которые выполнимы над объектом. Обычно, такая информация называется полномочиями (authority). Указатель, содержащий адрес объекта и полномочия, называется возможностью (capability). System/38 использует адресацию на базе возможностей, все системные указатели содержат как адрес, так и полномочия. В AS/400 способ предоставления пользователям полномочий по работе с объектами был изменен.

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

Предположим, мы хотим дать пользователю право выполнения одиночной операции над объектом, то есть предоставить программе пользователя однократный доступ или возможность модификации данных объекта, но не на постоянной основе. Однако после того, как доступ к системному указателю открыт, «закрыть» его невозможно.

Для ограничения полномочий пользователя и повышения степени защищенности IBM добавила в AS/400 методы предоставления временных полномочий. Одновременно, мы удалили полномочия из указателей всех пользовательских программ, оставив их только для указателей, используемых ОС в системном состоянии (подробности —в главе 7).

Так что говорить об AS/400 как о системе с адресацией на базе возможностей неправильно. За исключением только что указанного случая, такой способ адресации в AS/400 не используется.

Разрешение системных указателей

Системный указатель считается разрешенным, если содержит прямой адрес системного объекта. Указатель, содержащий символический адрес, называется неразрешенным. Символический адрес используется для поиска объекта в библиотеке и состоит из имени, типа и подтипа объекта, причем последний для поиска не требуется. Его значение определяется пользователем, и служит лишь для дальнейшей классификации объектов OS/400.

На рисунке 5.4 показан процесс разрешения системного указателя по команде «RESOLVE». Команда использует имя и тип системного объекта из неразрешенного указателя, а также запрашиваемые полномочия. Выполняется поочередный просмотр библиотек из списка библиотек, связанного с заданием, выдавшим данную команду. Просмотр длится, пока не будет найден заданный объект.

Рисунок 5.4 Разрешение системного указателя

Затем выполняется тройная проверка. Прежде всего, проверяется тип объекта, чтобы гарантировать корректный возврат объекта; затем, есть ли у пользователя права, указанные в команде «RESOLVE» (эта информация хранится в профиле пользователя); и, наконец, выясняется, возможен ли доступ к объекту (не был ли он заблокирован другим пользователем).

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

Другие типы указателей

Системный указатель обеспечивает доступ к системному объекту, но при выполнении некоторых операций нужно работать с данными, содержащимися внутри таких объектов. Для этого используются другие типы указателей. Но прежде чем рассказать о них, я хочу остановиться на внутренней структуре системного объекта.

Итак, системный объект состоит из двух основных частей: функциональной и пространственной. Содержимое функциональной части зависит от типа системного объекта, например, для программы — это последовательность команд. Пространственная часть системного объекта (часто называемая ассоциированным пространством) s просто байтовое пространство, используемое в качестве рабочего. Такая структура характерна для всех системных объектов, за единственным исключением: системный объект «пространство» не имеет функциональной части.

Необходимость отдельной пространственной части в объекте объясняется способом представления памяти в MI. Вспомните, что для поддержания независимости от нижележащей технологии, в MI нет понятия памяти в традиционном смысле; только объекты и ничего кроме них. Между тем, указатели и данные пользователей должны где-то храниться. Место для этого s пространственная часть системных объектов.

Рисунок 5.5 Системные объекты

Так как все системные объекты инкапсулированы, манипуляции с байтами внутри функциональной части невозможны s нельзя даже заглянуть внутрь ее. Очевидно, нужен некий способ доступа к информации, находящейся в пространственной части (рабочем пространстве). Этот способ предоставляет нам пространственный указатель.

Пространственный указатель очень похож на системный. Он имеет длину 16 байтов и содержит адрес. Отличие в том, что адрес из пространственного указателя указывает на некоторый байт где-то в пространственной части системного объекта. Таким образом, пространственные указатели можно использовать для доступа и манипуляции содержащимися там байтами.

Другое важное различие между двумя типами указателей состоит в операциях с адресом, которые каждый из них может выполнять. Адрес в пространственном указателе может быть изменен программой MI так, чтобы указывать на другой байт в том же пространстве. Адрес в системном указателе лишь указывает на начало объекта и изменить его нельзя. Пользователь, имеющий соответствующие права, может с помощью системного указателя получить пространственный указатель на объект. Второй объект, показанный на рисунке 5.5, также содержит пространственный указатель. Рисунок иллюстрирует, как указатель такого типа предоставляет доступ к байтовому пространству первого объекта.

В дополнение к системным и пространственным, в MI есть еще четыре типа указателей. Указатель данных аналогичен пространственному, но содержит описание

На рисунке 5.5. Вы можете видеть два системных объекта, каждый из которых имеет функциональную и пространственную части. Пространственная часть может содержать как указатели, так и данные. На рисунке пространственная часть второго объекта содержит системный указатель на первый системный объект. Системные указатели всегда указывают на системные объекты, но лишь на начало, так что с их помощью не много можно сделать. Это и понятно, ведь основное назначение указателя s обеспечить доступ к объектам. Но как быть, если надо проникнуть внутрь объекта и поработать с байтами?

типа данных, что позволяет рассматривать цепочку байтов внутри пространства как данные любого типа. В качестве аналогии можно привести указатель языка С. Указатель команд служит для определения места команды в последовательности и используется для выполнения переходов.

Четыре рассмотренных типа указателя (системный, пространственный, данных и команд) присутствовали в первом варианте System/38. Позднее для обеспечения доступа к внутренней памяти была добавлена специальная версия пространственного указателя s машинный пространственный указатель. В AS/400 с появлением ILE был добавлен новый процедурный указатель. Процедурные указатели используются в операциях вызова/возврата, рассмотренных в главе 4.

Характеристики системных объектов

Теперь можем, наконец, перечислить основные характеристики всех системных объектов (некоторые из них мы рассмотрим сейчас, а некоторые —в следующих главах).

Системные объекты должны быть явно созданы командой MI «Create».

Команда «Create» указывает на заданный пользователем шаблон, содержащий атрибуты и данные для объекта. Шаблон содержится в объекте-пространстве.

Атрибуты системного объекта могут быть материализованы.

Системный объект может быть явно удален.

Все системные объекты, встречающиеся в некотором контексте, имеют имена. Системный объект может не иметь имени, если на него нет ссылки в библиотеке или файловой системе. Пример — системный объект, используемый исключительно SLIC.

Адресация системных объектов обеспечивается посредством системных указателей.

Системные объекты содержат пространство, в котором находятся указатели и данные.

Системные объекты создаются либо как временные, либо как постоянные. Постоянный объект (persistence) остается в памяти системы, пока не будет явно уничтожен. Временный объект удаляется при всяком выполнении операции IPL (начальная загрузка).

Временные объекты могут быть помещены в группы доступа — системный объект, позволяющий объединять несколько объектов и работать с ними как с целым.

Права доступа к системным объектам контролируются аппаратно.

Использование объекта синхронизируется посредством механизма замков.

Постоянство объекта (часть характеристики 8) требует некоторых дополнительных пояснений. Итак, постоянный объект продолжает существовать в системе, пока не будет специально уничтожен. Присутствуя в памяти, он может легко использоваться совместно разными пользователями. Именно этим AS/400 сильно отличается от других систем, которые требуют располагать разделяемую или предназначенную для длительного хранения информацию в отдельной файловой системе. Позже мы рассмотрим, как одноуровневая память AS/400 поддерживает постоянство объектов.

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

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

Как уже упоминалось, временные объекты исчезают при каждой загрузке системы. В обычной системе области временной памяти связаны с создавшими их заданиями, не могут разделяться пользователями и исчезают, когда задание завершено. В AS/400 вся память, содержит ли она постоянные или временные объекты, может разделяться пользователями и объекты остаются в системе даже после завершения задания. При разработке AS/400 в качестве некоторого, отличного от завершения задания, момента удаления временных объектов была выбрана загрузка системы. Это оказалось удобным, так как снижает накладные расходы. Например, если бы мы разрушали временную библиотеку задания по завершении последнего, то производительность при исполнении остальных заданий несколько снижалась бы. И мы решили перенести накладные расходы на время выполнения загрузки.

Примером временного объекта может служить индекс области данных, обеспечивающий проекцию базы данных: если он создается для выполнения единственного запроса к базе данных, то нет смысла делать его постоянным. Обратите внимание, что постоянный объект может пережить крах системы, иногда объекты и создаются постоянными только для того, чтобы не потерять их в случае сбоя системы. Напротив, если для восстановления системы ее потребуется перезагрузить, то все временные объекты будут потеряны. Внутренние детали обработки системой временных и постоянных объектов будут объяснены далее.

Программные объекты

До сих пор мы рассматривали только системные объекты и их характеристики. Однако в MI есть другие элементы данных, также называемые объектами, но имеющие очень малое сходство с обычными, что создает еще одну терминологическую проблему.

В главе 4 мы рассмотрели содержимое оригинального шаблона программы MI — последовательность команд и таблицу определения объектов ODT. ODT описывает операнды, используемые программой. В результате неудачного выбора имен проектировщики MI для System/38 называли эти операнды объектами, а точнее программными объектами. Таким образом, двухбайтовое двоичное число считается объектом.

Программные объекты не имеют с системными объектами MI ничего общего, кроме названия. Но так как программный объект очень легко спутать с системным объектом типа «программа», то мы, для простоты, будем с этого момента использовать слово «объект» только для обозначения системных объектов MI.

Внутри системного объекта

Хотя в MI нет концепции памяти, все процессоры AS/400 используют физическую память, включая основную память и диск. Системные объекты, расположенные ниже MI, реализованы как строго определенные структуры, хранящиеся в этой памяти. За создание и управление этими структурами данных отвечает компонент управления объектами в SLIC. Давайте рассмотрим формат этих структур данных и их использование для представления системных объектов MI.

Сегментированная память

Понятия памяти и дискового пространства верны только ниже MI. В отличие от OS/ 400, SLIC «знает» о наличии этой памяти и работает с нею. Вся основная память и дисковое пространство в AS/400 находятся внутри большого единого адресного пространства, обычно, называемого одноуровневой памятью. Объем этой памяти равен общему числу байтов, на которое может ссылаться 64-разрядный адрес8.

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

Адресное пространство AS/400 логически разделено на блок последовательных байтов, называемых сегментами. В System/38 и первых AS/400 использовалось два размера сегмента: 64К и 16М. 16-мегабайтный сегмент состоял из 256 сегментов по 64К и иногда назывался сегментной группой. При переходе на 64-разрядную адресацию сегменты меньшего размера были исключены, остался только сегмент размером в 16М.

Сегменты не перекрываются и всегда начинаются с границы. Это означает, что 24 младших (самых правых) бита адреса первого байта каждого сегмента размером 16М всегда равны 0. Каждый 16-мегабайтный сегмент уникально задается 40 старшими (самыми левыми) битами 64-разрядного адреса.

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

Структура системного объекта

На рисунке 5.6 изображен формат системного объекта в одноуровневой памяти. Первые 32 байта содержат заголовок, предоставляющий информацию о самом сегменте. Далее следует заголовок EPA (Encapsulated Program Architecture). ЕРА была создана для спецификации внутренней структуры инкапсулированных объектов System/38, а затем та же внутренняя структура была перенесена в AS/400. Заголовок ЕРА содержит атрибуты (свойства) общие для всех системных объектов, независимо от типа. Заголовок сегмента и заголовок ЕРА вместе занимают первые 256 байтов всякого системного объекта.

⁹System/38 и первые модели AS/400 использовали размер страницы в 512 байтов. Размер страницы был увеличен до 4К при переходе на 64-разрядную RISC-аппаратуру.

⁸Число байтов, адресуемых 64-разрядным числом, настолько велико, что большинство людей не могут соотнести его с чем-либо, что можно «пощупать руками». Когда в AS/400 был 48-разрядный адрес, мы, бывало, говорили, что число адресуемых байтов равно расстоянию от Земли до Солнца и обратно в миллиметрах. Для 64-разрядного адреса нужна какая-то новая аналогия.

Рисунок 5.6. Структура системного объекта

Рисунок 5.6. Структура системного объекта

Каждый тип объекта содержит свойства, присущие только ему: свойства программы уникальны по сравнению с областью данных, и наоборот. Эти индивидуальные свойства содержатся в специфическом заголовке (customized header) объекта, следующем после заголовка ЕРА.

После трех заголовков следуют компоненты, составляющие данный объект: например, за специфическим заголовком программы размещается последовательность команд. Так как все системные объекты имеют пространственную часть, пространственный компонент присутствует всегда. В MI он называется ассоциированным пространством. Конкретный набор компонентов и порядок их следования зависят от типа объекта.

Типов системных объектов слишком много, для того чтобы подробно описывать специфические заголовки и компоненты объектов. Однако некоторые примеры мы рассмотрим.

Многосегментные объекты

Как мы уже говорили, системные объекты занимают один или несколько сегментов и всегда начинаются с границы сегмента. Первый сегмент называется базовым — его имеет каждый объект, и на него всегда ссылается системный указатель. В зависимости от типа объекта, он может занимать один или несколько вторичных сегментов, большинство объектов занимают их ассоциированным пространством. Ни один сегмент не может быть частью более чем одного системного объекта.

На рисунке 5.7 показан системный объект, занимающий два сегмента, при этом системный указатель ссылается на базовый сегмент. Обратите внимание, что у каждого сегмента — свой заголовок. Заголовок сегмента содержит информацию о сегменте, а не о содержащемся в нем объекте. В заголовке сегмента также содержатся адреса, связывающие сегменты друг с другом. Заголовок ЕРА содержится только в базовом сегменте. За заголовком ЕРА, также только в базовом сегменте, следует специфический заголовок объекта.

Рисунок 5.7 Многосегментные объекты

Выделение сегментов происходит при создании системного объекта посредством команды «Create xxx», где «xxx» — тип создаваемого объекта. На рисунке 5.8 показаны исходные параметры и результаты команды «Create» на уровне MI. Эта команда использует пространственный указатель для доступа к шаблону объекта, содержащегося в пространственном объекте. Читателю следует иметь в виду, что команды «Create xxx» MI — это не то же самое, что и команды «CRTxxx» OS/400. Например, команда OS/400 «CRTRPGPGM» должна выполнить ряд предварительных шагов, прежде чем дело дойдет до заключительного прохода компиляции программы — вызова «Create» в MI. Исполнение этой команды на уровне MI приводит к созданию в одноуровневой памяти базового и вторичных сегментов.

Рисунок 5.8 Создание объекта

Для отражения наличия нового объекта обновляются различные справочники, поддерживаемые SLIC. Компоненту управления памятью нужен доступ к сегменту, поэтому выполняется обновление одного из справочников компонента. Если объект создается в библиотеке (аналогичный термин ниже MI — контекст), то туда также нужно внести его имя и местоположение. Если библиотека не задана, то объект помещается в текущую библиотеку задания, вызвавшего команду «Create» (одна библиотека из списка для каждого задания всегда обозначается как текущая). Аналогично, следует обновить профиль пользователя или группы, чтобы обозначить владельца нового объекта. Заключительный этап — создание системного указателя на объект и возвращение его пользователю, запросившему о создании.

Содержимое заголовков

Теперь, после рассмотрения структуры системных объектов и их отображения на сегменты памяти можно перейти к рассмотрению содержимого заголовков сегмента и ЕРА. Как мы видели на рисунке 5.6, заголовок сегмента занимает первые 32 байта каждого сегмента, составляющего системный объект. Заголовок ЕРА присутствует только в базовом сегменте системного объекта.

Заголовок сегмента

Заголовок сегмента содержит следующую информацию:

байт типа;

биты флагов:

существования (постоянный или временный);

авторасширения;

наличия в сегменте тегов;

другие;

число выделенных для него страниц;

адрес базового сегмента объекта;

адрес ассоциированного пространства объекта.

Последние два адреса не следует путать с системным указателем и пространственным указателем на системный объект. Они представляют собой 64-разрядные адреса, используемые SLIC.

Байт типа определяет, что это за сегмент. Есть две категории типов сегментов: входящие в состав объектов MI, и используемые только SLIC ниже MI. Ранее мы говорили только о сегментах для объектов MI. Однако, есть целая категория сегментов для структур данных SLIC, которые не являются частью системных объектов MI. Эти сегменты, в отличие от объектов, не рассматриваются как единое целое.

Мы уже рассмотрели два типа сегментов, входящих в состав системного объекта: базовый и сегмент ассоциированного пространства. Всего же в состав различных системных объектов MI могут входить сегменты более дюжины других типов. О некоторых из них мы поговорим в следующих главах.

Примерно 40 типов сегментов используются только SLIC. Все его элементы, начиная от таблиц управления памятью до рабочей области, используемой транслятором, имеют свои типы сегментов. Обсуждение этих типов сегментов также имеет смысл пока отложить. На данный момент важно лишь то, что эти сегменты существуют, и что они создаются и управляются аналогично сегментам, используемым для системных объектов.

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

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

Бит наличия тегов указывает на присутствие в сегменте указателей MI. В главе 2 мы рассматривали расширения архитектуры PowerPC и в том числе и этот специальный бит. Напомню, что он связан с каждым адресом MI (16-байтовым указателем) и предотвращает несанкционированное изменение адреса. Биты тега входят в состав основной памяти AS/400, но не видимы программам MI. При перемещении страницы на диск, компонент управления памятью должен также переместить туда скрытые биты тега. Бит наличия тегов сообщает компоненту управления памятью, придется ли тому выполнять обработку тегов для этого сегмента. Подробнее биты тегов рассматриваются в главе 8.

Два оставшихся поля заголовка сегмента представляют собой адреса: первый — базового сегмента, второй — следующего вторичного сегмента, которым для системного объекта обычно является адрес ассоциированного пространства. Эти два адреса позволяют связать друг с другом сегменты многосегментного объекта.

Обратите внимание, что адреса, используемые ниже MI в заголовках и где-либо еще — 64-разрядные аппаратные. В MI адреса всегда содержатся внутри указателя и занимают 128 бит (16 байтов). Указатели защищают хранящиеся в них адреса от несанкционированного изменения и использования, а также помогают обеспечить независимость MI от технологии. Ниже MI нет ни такой защиты, ни аппаратной независимости. Именно по этой причине все пользователи MI, включая саму OS/400, не допускаются ниже уровня MI.

Заголовок EPA

Заголовок ЕРА содержится в базовом сегменте всякого системного объекта и содержит следующую информацию об объекте:

байт атрибутов:

постоянный ли;

подвешенный ли;

поврежден ли;

присутствует ли группа доступа;

трассируется ли;

участвует ли в транзакции;

идентификация объекта:

тип;

подтип (определяется пользователем);

— имя;

атрибуты пространства:

фиксированной или переменной длины;

начальное заполнение;

размер;

общий размер;

номер версии;

время создания;

адрес профиля пользователя;

адрес контекста;

адрес группы доступа;

адрес специфического заголовка;

другая информация и адреса.

Атрибуты объекта содержатся в начале заголовка ЕРА. Содержимое байта атрибутов проверяется всякий раз, когда системный указатель используется для обращения к объекту. Первый атрибут указывает, является ли объект постоянным или временным. Этот атрибут, значение которого также задано битом существования в заголовке сегмента, повторяется здесь для облегчения проверки.

Биты подвешенности и поврежденности объекта определяют его состояние. Подвешенным считается объект, у которого доступны только заголовки, а содержимого не существует. Предположим, что владелец системного объекта явно удаляет его. Что будет, если кто-либо еще обладает указателем на этот объект и попытается воспользоваться им после того, как объект уничтожен? Он обнаружит подвешенный объект. Система определит, что объект более не существует, и предпримет соответствующие действия.

При разрушении постоянного объекта его адресное пространство повторно не используется, что устраняет необходимость поиска всех указателей на удаленный объект, чтобы пометить их как недействительные. Это снимает также проблемы защиты и целостности, которые возникают в тех случаях, когда на место удаленного объекта распределяется новый, а у какого-нибудь пользователя сохранился указатель на старый объект. В других системах применяются сложные схемы «сборки мусора» для поиска указателей на удаленный объект. В AS/400 это не нужно[ 45 ]. При этом дисковое пространство, за исключением занятого заголовками удаленного объекта, очищается.

Можно выделить два вида повреждения объекта: жесткое и мягкое. Жесткое означает, что объект невозможно использовать по назначению — он поврежден безвозвратно, его лучше удалить. В случае мягкого повреждения из объекта все же можно извлечь некоторые данные. При обнаружении такого повреждения OS/400 начинает процесс восстановления.

Бит поврежденности используется для индикации проблем с объектами в MI. Один из основных определителей повреждения — компонент управления памятью. Источник повреждений — плохие сектора на диске. Если компонент управления памятью не способен считать сектор, он сообщает об этом установкой бита повреждения.

Другие биты заголовка ЕРА указывают на наличие группового доступа к данному объекту, на выполнение трассировки объекта и участие его в транзакции. Подробнее эти атрибуты будут рассмотрены в главе 6.

Для идентификации объекта в заголовке ЕРА зарезервировано три поля. Одно из них содержит тип объекта, а другое — подтип. Тип объекта — один из типов системных объектов MI. Поле подтипа определяется пользователем, при этом программисты OS/400 рассматриваются как пользователи системных объектов MI. Только для некоторых типов объектов (таких как пользовательское пространство) подтипы могут определяться за пределами Рочестера. Третье поле — поле имени, оно содержит имя объекта в контексте.

Атрибуты пространства указывают, является ли размер пространства постоянным или переменным, каково начальное заполнение пространства (было ли оно очищено или обнулено), а также размер пространства. Поле общего размера объекта содержит размер всех сегментов объекта. Номер версии и время создания позволяют определить, когда был создан объект.

Некоторые поля заголовка ЕРА содержат адреса. Наиболее важны из них: адрес пользовательского профиля владельца и создателя, адрес контекста, содержащего имя объекта, адрес группы доступа (если объект входит в нее), и адрес специфического заголовка объекта. Заголовок ЕРА содержит и другую информацию, а также адреса, используемые компонентами системы, которые еще будут обсуждаться.

Примеры объектов

На рисунке 5.9 приведено четыре примера системных объектов. Простейшим системным объектом является пространство, занимающее лишь один сегмент. У него есть только заголовки сегмента и ЕРА и пространство для данных пользователя.

Пример объекта, занимающего два сегмента — независимый индекс, обычно называемый просто индексом. Его основное назначение — поддержка пользовательского индекса OS/400. Базовый сегмент индекса содержит заголовки сегмента и ЕРА, заголовок (специфический) индекса и двоичное дерево. В следующей главе мы увидим, как двоичное дерево используется в AS/400 для реализации индексов. Второй сегмент индекса — сегмент ассоциированного пространства, то есть байт типа в заголовке этого сегмента указывает, что это ассоциированное пространство. Этот сегмент также содержит пользовательские данные для индекса.

Кроме того, на рисунке 5.9 показаны два примера объектов, занимающих три сегмента.

Рисунок 5.9 Примеры объектов

Первый из них — программа. Базовый сегмент программы содержит заголовки сегмента и ЕРА, заголовок (специфический) программы, последовательность команд и код инициализации программы. Второй сегмент занят ассоциированным пространством, содержащим пользовательские данные для программы. Третий — это сегмент таблицы определения материализации MDT (materialization definition table), содержащий шаблон и карту объектов программы, необходимые для материализации программы. При удалении пользователем шаблона программы, третий сегмент исчезает, и программа занимает только два сегмента.

Последний объект на рисунке — индекс области данных. Как всегда, базовый сегмент содержит заголовки сегмента и ЕРА, заголовок (специфический) индекса области данных, альтернативную таблицу сортировки для этого индекса, таблицы индекса и двоичное дерево. Второй, как обычно, — сегмент ассоциированного пространства. Третий — сегмент отложенной коррекции. Для индекса области данных можно запросить отложенную коррекцию. В этом случае изменения, такие как добавление или удаление ключа, не вносятся в индекс немедленно. Вместо этого, информация о них записывается в сегмент отложенной коррекции до момента следующего открытия файла. Отложенная коррекция позволяет не ждать завершения операции коррекции, пока индекс используется. Однако прежде чем индекс используют в следующий раз, изменения будут внесены.

Выводы

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

Объекты — основа AS/400. Они не были добавлены поверх существующей системы, как это часто бывает. Объекты были частью AS/400 с самого начала.

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

Глава 6

Интегрированная база данных

В сегодняшнем бизнесе конкуренция постоянно усиливается. Чтобы достичь успеха приходится производить больше продукции за меньшую стоимость и быстрее, чем раньше. В нашем стремительном мире остановиться — значит проиграть. Как сказал, однажды американский философ Йоги Берра (Yogi Berra), «рано быстро становится поздно».

Очень часто выжить в условиях острой конкуренции помогают оперативные данные. Многие бизнесмены понимают теперь, что информация — возможно, самое ценное, что у них есть. Часто выборка, обновление и сохранение данных повседневной деятельности выполняются некоторой прикладной программой, например, бухгалтерской или приема заказов. Мы, специалисты, обычно, называем программы такого типа приложениями оперативной обработки транзакций OLTP (online transaction processing). Приложение OLTP часто интерактивно, то есть обновление данных происходит в процессе оперативных транзакций. Для легкого и быстрого доступа к оперативной информации сегодня ее обычно хранят в реляционной базе данных.

Компьютерная революция позволила легко собирать и дешево хранить большие объемы оперативных данных. Многие компании хранят свои данные за многие годы, веря, что это может когда-нибудь пригодиться. Но у большинства из них остается вопрос: «Мы знаем, что внутри этих данных скрыта бесценная информация о наших рынках сбыта, товарах, услугах и клиентах. Но как извлечь эту информацию?» Традиционно, анализ данных в поисках необходимой информации выполнялся вручную. Но в последние несколько лет стало очевидно, что автоматизация анализа данных не только значительно облегчает этот процесс, но и экономически выгодна. Часто ПО анализа данных называют системами поддержки принятия решений (decision-support), и говорят о преобразовании данных сначала в информацию, а затем в знания.

Словосочетания складирование данных (data warehousing) и разработка данных[ 46 ] (datamining), еще несколько лет назад известные лишь узким специалистам, стали частью повседневного словаря делового человека. Рассказы в прессе о компаниях, которым с помощью этих технологий удалось выйти на передовые позиции в своей отрасли, побудили многие фирмы следовать тем же путем. Хранилища данных, где накапливается информация из собранных оперативных данных, — возможно, одна из наиболее быстро распространяющихся информационных технологий для бизнеса. Некоторые консультанты предсказывают, что в следующие несколько лет примерно треть всех расходов на информационные технологии будет связана с ней.

Какое отношение все это имеет к AS/400? Вероятно, в ближайшие несколько лет с помощью AS/400 будет реализовано больше хранилищ данных, чем с помощью какой-либо другой системы. Причина проста: именно DB2/400 — база данных AS/400 — наиболее широко используемая многопользовательская база данных во всем мире, и именно под ее управлением сосредоточен наибольший объем оперативных данных.

Обычно, этот факт удивляет даже в заказчиков AS/400. IBM не продает DB2/400 как отдельный продукт, поэтому многие просто не знают о ее позициях на рынке и часто считают наиболее широко распространенными базы данных от Oracle, Sybase или Microsoft. Очень немногие знают о DB2/400.

Учитывая объем данных, хранящихся в базах DB2/400, можно представить, сколь много хранилищ данных будет создано на AS/400. По оценке IBM более 60 процентов заказчиков AS/400 в следующие несколько лет станут использовать те или иные системы поддержки принятия решений. В этой главе мы рассмотрим все возрастающую роль баз данных и то, как AS/400 удается держать первенство в этой области. Мы остановимся также на истории DB2/400 и на том, как она интегрирована в AS/ 400. Но сначала, давайте разберемся, что такое DB2/400?

База данных без имени

Много лет назад мы решили интегрировать мощную реляционную базу данных в каждую System/38. Затем эта идея перекочевала и в AS/400. Мы считали, что способность полнофункциональной системы управления базой данных (СУБД) эффективно и надежно обрабатывать большие объемы информации, станет хорошей основой всех приложений для бизнеса. Вместо того, чтобы делать базу данных отдельным продуктом, мы просто встроили ее, даже не побеспокоившись об отдельном имени. Незаметно для глаз многие годы безымянная база данных тихо делала свое дело. В результате, даже не все наши заказчики (40 процентов, как показали проведенные несколько лет назад исследования) знают, что на них ежедневно работает такая мощная база данных.

Это и хорошо, и плохо. Хорошо, что многие заказчики не предпринимали никаких специальных усилий для управления своей базой данных, а просто пользовались, не испытывая при этом никакой потребности в помощи администратора базы данных. (Этим база данных AS/400 отличается от некоторых других, для управления которыми требуется персонал).

Плохо же то, что некоторые пользователи в один прекрасный день решили добавить на свои AS/400 базу данных, не зная, что она там уже есть. Действительно, пользователи почти всех современных компьютерах, включая ПК, отдельно покупают и интегрируют в систему реляционные базы данных. Поэтому, решили такие заказчики, несомненно, стоит потратиться и установить реляционную базу данных и на AS/400[ 47 ].

Кроме того, нам, сотрудникам IBM, было трудно объяснить, где собственно находится база данных AS/400, так как она не сосредоточена в одном месте. Интегрированная природа системы ведет к тому, что база распределена по всей системе. С другой стороны, обычные базы данных — это отдельные программные компоненты, работающие поверх ОС. Чтобы добраться до обычной базы данных, программе необходимо пройти через ОС или использовать совершенно отдельный интерфейс.

Между тем, интегрированная частично над MI, и частично в SLIC, база данных AS/ 400 более эффективна, чем базы, построенные поверх существующих систем. База данных AS/400 тесно связана с другими компонентами системы и взаимодействует с ними способами, недоступными обычным базам.

В 1994 году мы решили дать своей базе данных имя, выбрав «DB2 для OS/400» в отражение того, что наша база данных — часть семейства реляционных баз данных

IBM DB2[ 48 ]. Фамильное сходство заключается, в основном, во внешних утилитах и поддержке распределенных баз данных. Внутренне каждый продукт реализован по-своему. Но имя DB2 все помогает устранить впечатление, что у AS/400 нет современной, надежной базы данных.

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

Давайте рассмотрим, как AS/400 поддерживает хранилища и обработку данных, а затем разберем некоторые фундаментальные концепции DB2/400.

Хранилища данных

Итак, мы убедились в важности для современного бизнеса оперативного хранения и использования данных и обсудили, чем в этом случае может помочь реляционная база данных. Оперативные данные динамичны, часто обновляются, оптимизированы для транзакций. Информационные данные — обобщают оперативные, обновляются редко (может быть даже никогда), и хранятся в форме, оптимизированной для принятия решений, отдельно от оперативных, зачастую даже на другой машине. Именно информационные данные и составляют хранилище данных.

Следует ясно понимать, что хранилище данных — это концепция, а не конкретный продукт. Это набор средств для систематизации информационных данных, их хранения и анализа для принятия решений. Хранилище данных AS/400 состоит из четырех основных компонентов, а именно:

средств трансформации и преобразования данных для заполнения хранилища;

сервера базы данных;

аналитических средств и программы пользовательского интерфейса;

средств управления информацией о самом хранилище.

Преобразование оперативных данных в информационные

Создание хранилища данных требует преобразования оперативных данных в информационные. Для этого используются так называемые средства трансформации (transformation tools) или средства преобразования (propagation tools). Их задача — не просто извлечь данные из одной или нескольких оперативных баз, но и преобразовать их в форму, подходящую для хранения.

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

Программа может проанализировать собранные данные для прогноза потребностей в товарах, или для оценки доходов по сравнению с прошлым годом. Для анализа такого типа — быстрого выявления тенденций и потенциальных проблем — данные должны быть преобразованы. Аналитической программе нужна сводка информации из оперативной базы. Средства преобразования периодически собирают с компьютеров оперативные данные, трансформируют их в сводный формат и помещают в хранилище данных. Обратите внимание, что большинству аналитических программ не требуется постоянная синхронизация данных в хранилище и оперативных. Автоматическое обновление хранилища данных осуществляется с разной периодичностью: раз в неделю, раз в день или каждые 10 минут. Есть много программ как IBM, так и других производителей, позволяющих выбирать данные из баз (DB2 или других) и импортировать их непосредственно в склад данных AS/400.

Серверы баз данных

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

Итак, два важнейших аспекта поддержки хранилищ данных — параллельная обработка и многомерные базы данных (MDD).

Параллельная обработка

Различные приемы параллельной обработки позволяют базе данных полностью задействовать все аппаратные возможности. Выборка и анализ больших объемов информации может требовать очень больших ресурсов. По счастью, при обработке базы данных доступ к ней может осуществляться параллельно, после чего собранные данные можно анализировать независимо и также параллельно. Обработка баз данных — один из примеров практического использования массового параллелизма, который мы вкратце затронули в главе 2.

IBM несколько модифицировала AS/400 и DB2/400, что позволило применить массовый параллелизм при работе с базой данных. Впервые поддержка параллельной обработки ввода-вывода появилась в V3R1, что позволило воспользоваться возможностями аппаратной архитектуры AS/400, имеющей как основные процессоры, так и вспомогательные, и ввести параллельную обработку на уровне процессора ввода-вывода (IOP) для одного задания. Мы подробно рассмотрим IOP в главе 10, а сейчас, забегая вперед, скажу, что в мощной AS/400 их может быть установлено несколько сотен, причем к разным IOP подключают множество дисковых накопителей. Параллельный ввод-вывод позволяет обрабатывать пользовательский запрос к базе данных несколькими IOP одновременно. Таким образом, устраняется одна из самых серьезных проблем, мешающих многим системам достичь высокой производительности: задержки при выполнении ввода-вывода.

В главе 2 мы говорили о поддержке SMP в AS/400, когда все основные процессоры работают параллельно с общей памятью. При большинстве видов обработки отдельные задания выполняются на разных процессорах, при необходимости используя общие области памяти. При обработке запросов к базе данных каждый основной процессор может обрабатывать часть задачи. Именно так работает средство параллельной обработки DB2/400. Запрос разбивается на отдельные, независимые подзапросы, которые выполняются параллельно несколькими основными процессорами, что позволяет значительно сократить время обработки. Задать использование нескольких процессоров при обработке запроса можно с помощью соответствующей опции команды «CHGQRYA» (Change Query Attribute).

Данный метод повышает производительность таких запросов, как поиск в таблице, группирование (group-by), поиск в индексе и соединение (join). Поддержкой параллельной обработки базы данных на системах SMP пользуются также некоторые внутренние функции SLIC, например, построение индекса (подробно об этом мы поговорим в разделе «Машинный индекс»). Параллелизм присутствует на всех системах версий 3 и 4, но параллельное построение индекса — только на RISC-системах.

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

IBM называет такую конфигурацию MPP слабо связанной параллельной системой базы данных, в связи с отсутствием разделения памяти за пределами отдельной системы в кластере. Здесь используется подробно обсуждавшийся в главе 2 подход shared-nothing, похожий на тот, что применяется в SP2. Различие в том, что узлы кластера AS/400 находятся в разных физических корпусах, но, несмотря на это, для пользователя кластер выглядит как единая база данных.

Технология слабо связанной параллельной базы данных позволяет разбивать запросы на части, с которыми может справиться отдельный узел. В отличии от SMP-па-раллельной базы данных, у каждого узла — собственные память и дисковое пространство. Каждый узел кластера работает с порцией физического файла или таблицы, и запрос к нему выполняется для соответствующей порции файла. Каждый узел может содержать один или несколько процессоров, ведь узел — это просто AS/400.

Приложение, выполняющееся на любом компьютере кластера, может работать с базой так, как если бы она полностью размещалась на этом компьютере. Распределенность базы по узлам кластера делает DB2/400 прозрачной как для приложений, так и для конечного пользователя. Для задания имен системам в группе узлов в CL были введены новые команды, к некоторым командам были добавлены новые параметры для поддержки распределения файлов базы по узлам. После рассредоточения по узлам, файл при выполнении операций вставки, обновления и удаления выглядит как локальный.

Главное преимущество слабо связанных параллельных систем — отсутствие верхнего предела количества узлов, что означает практически неограниченный рост производительности и емкости. Возможности расширения концепции кластеров AS/400 в будущем мы рассмотрим в главе 12.

Многомерные базы данных (MDD)

Реляционные базы данных организованы в виде двумерных таблиц. В MDD имеется одно или несколько дополнительных измерений. Например, Вам надо оценить свои доходы от продаж, рассмотрев в отдельности сводки по товарам, по регионам и по времени. В этом случае лучшую наглядность Вам обеспечит трехмерная структура данных со шкалой измерения по товарам на одной оси; временем в днях, неделях или месяцах — на второй; и географическими данными — на третьей. В результате получится куб, очень похожий на трехмерную электронную таблицу, в каждой ячейке которой — величина доходов от продажи. Далее можно использовать различные средства анализа продаж товаров в регионах в течение некоторого периода времени.

AS/400 поддерживает многомерные структуры данных непосредственно в самой базе данных DB2/400 или с помощью продуктов, разработанных бизнес-партнерами. Преимущество многомерных структур данных состоит в возможности быстро получить ответ на поставленный вопрос в виде среза данных по любому измерению или прохода сквозь структуру для получения данных новых уровней. Поскольку время ответа на запросы обычно очень мало, такой многомерный анализ часто называют оперативной аналитической обработкой OLAP (on-line analytical processing).

Иногда различным подразделениям одной организации требуются информационные данные в разных формах. Внутри MDD можно создавать специализированные хранилища данных (data mart), которые содержат информационные данные, соответствующие потребностям конкретного отдела или рабочей группы. В этом случае хранилище данных всей организации состоит из набора таких специализированных хранилищ для отдельных структурных единиц[ 49 ].

Анализ данных и инструментарий конечных пользователей

Термином «интеллектуальный бизнес» (business intelligence) обозначают методы обработки информации, применяемые для принятия решений в бизнесе. Средства интеллектуального ведения бизнеса — это программные пакеты, используемые для анализа данных в хранилище данных на AS/400. Обычно, эти программы работают на ПК и способны обращаться к хранилищу данных на AS/400 напрямую. Есть три основных категории бизнес-информационных средств:

программы поддержки принятия решений DSS (decision support system);

управленческие информационные системы EIS (executive information system);

средства разработки данных.

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

EIS объединяют средства поддержки принятия решений с некоторыми расширенными возможностями анализа. Обычно, они имеют доступ к средствам за пределами хранилища данных, например, могут использовать оперативные новости из Интернета для получения информации с мировых рынков. Как и DSS, EIS предполагает наличие у спрашивающего некоторого представления о том, что именно следует искать.

И EIS, и DSS обеспечивают поиск нужной пользователю информации путем проверок. Но как быть, если Вы не можете четко сформулировать вопрос? Вы знаете, что в базе данных скрыта важная информация, но не можете придумать, как до нее добраться. Тогда Вам нужна разработка данных — средство принятия решений на основе открытий.

Разработка данных позволяет отыскивать информацию при незначительном объеме указаний от пользователя или вовсе без таковых. Система выполняет поиск шаблонов и связей. На практике существует бесконечное множество вариантов такого способа поиска. Например, розничный торговец может использовать разработку данных для того, чтобы определить, какие товары покупаются вместе. Анализ и оценка привычек покупателей очень полезны при оценке спроса на товар, или выявлении групп покупателей с наивысшим потенциалом. Разработка данных используется также в банковском деле для выявления подделок кредитных карт: путем «просеивания» больших объемов информации можно выявлять отклонения от нормы.

Технология разработки данных пришла из мира искусственного интеллекта. Средства IBM для поиска шаблонов и взаимосвязей данных комбинируют нейронные сети и статистические алгоритмы. Нейронная сеть поддерживает основной шаг разработки данных в процессе открытия знаний. Соответствующая технология была разработана в Рочестере в период проекта Fort Knox (подробнее об этом — в Приложении) и впервые появилась на рынке в начале 90-х годов в виде утилиты для AS/400. Теперь же она — основа всей разработки данных в IBM.

Управление хранилищем данных

Метаданные — это данные о данных. Они используются для управления хранилищем данных. Существуют две формы метаданных — технические и бизнес-данные. Первые содержат описания оперативной базы данных и хранилища данных, что позволяет перемещать данные из оперативной базы в хранилище.

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

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

Эволюция реляционной базы данных

Первая коммерческая база данных с реляционными возможностями появилась в System/38. Эта уникальная технология опережала другие реляционные базы примерно на три года, что позволило System/38 выйти на передовые позиции на рынке.

Разработчики System/38 искали более эффективный способ обработки записей, по сравнению с System/3. Первая System/3 была разработана как машина единичных записей. Она поддерживала только пакетную обработку, то есть приложение должно было обработать все записи в файле одну за другой. Первые записи размещались на перфокартах, колода перфокарт составляла файл. Позднее, появилась возможность хранения файлов на диске, хотя обрабатывались они по-прежнему с помощью перфокарт.

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

Позднее в System/3 была добавлена интерактивная обработка. Применение дисков позволило обращаться к записям в произвольном порядке. Поиск нужной записи осуществлялся с помощью индекса — небольшого файла, в котором каждой записи основного файла соответствуют лишь два поля. Первое содержит значение ключа, а второе — дисковый адрес записи с совпадающим значением. Для сортировки записей индекса по значениям ключа использовалась особая программа. Затем индекс сохранялся на диске вместе с основным файлом.

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

System/34 была первой моделью семейства System/3, предназначенной для работы в интерактивном, а не в пакетном режиме. Размеры памяти в System/34 были также невелики, так что IBM решила ускорить поиск нужной записи в индексе, а для этого — устранить необходимость считывать индекс с диска.

Часть дорожек диска была зарезервирована для индекса, для контроллера диска была разработана специальная аппаратура. Желаемое значение ключа процессор передавал дисковому контроллеру. Затем контроллер начинал считывать информацию дорожки, отыскивая значение ключа. Обнаружив искомое, аппаратура контроллера считывала следующее поле адреса и возвращала его процессору. Процессор использовал полученный адрес для считывания целой записи из некоторой другой части диска.

Эта операция была названа сканированием. Функция сканирования значительно повысила эффективность интерактивной обработки, благодаря полному устранению этапа обращения к диску для считывания индекса. Но при этом потребовалось встроить в памяти еще один небольшой индекс. Индекс в памяти указывал, на какой индексной дорожке диска следует выполнять поиск. Позднее аналогичная операция сканирования была реализована в System/36 для обработки файлов.

Для System/38 также была важна очень высокая эффективность интерактивной обработки. Недостатком описанной процедуры сканирования была ее слишком тесная привязка к аппаратуре. Были также и другие ограничения: максимально возможное число индексов, ограничение способов их обработки и др. Так как System/38 должна была иметь одноуровневую память, разработчики решили поместить все файлы и индексы в эту большую память.

Если вернуться назад к только что описанной файловой структуре, то мы увидим двумерную таблицу, где строки —это записи, а столбцы — поля записей. Разработчики посчитали, что наиболее эффективным будет организовать файл System/38 просто как двумерную таблицу в памяти. Они также полагали, что производительность обработки повысится, если таблицу обрабатывать «на месте» без сортировки записей. Чтобы добиться этого, они встроили индекс в таблицу так, что сортировка просто не требуется (подробнее об этом — далее, в разделе «Машинные индексы»). По сути, предполагалось, что в System/38 никогда не будет программы сортировки.

Однако, такая программа была и есть. Ее написал Дик Бэйнс, назвав «Conversion Reformat Utility», вероятно, чтобы скрыть ее сущность и предотвратить использование прикладными программистами в новых проектах[ 50 ]. Эта программа, тем не менее, была — а, может быть, есть и по сей день — самым быстрым способом сортировки и выборки записей из больших файлов. Джим Слоан (Jim Sloan), бывший разработчик и проектировщик, участвовавший в создании компилятора CL, разработал в составе своего набора QUSRTOOL утилиту для пользователей, интерфейс которой к этой программе сортировки позволял использовать внешние имена полей.

В процессе разработки базы данных Перри Тейлор (Perry Taylor) случайно наткнулся на технический отчет Е. Ф. Кодда (E. F. Codd). Кодд, который считается создателем реляционной базы данных, работал над проектом System/R (R — реляционная) в исследовательском центре IBM в Калифорнии. Базой в определении Кодда была двумерная таблица, над которой можно было выполнять четыре элементарных операции. Первая операция — упорядочение (order) — позволяла обрабатывать строки или столбцы в определенном порядке по ключевому полю; вторая — выборка (selection) — выбирать записи по значению ключевого поля; третья — проекция (projection) — осуществлять выборку из таблицы заданных полей; и наконец, четвертая — соединение (join) —рассматривать несколько таблиц как одну большую. Таким образом, реляционная база данных представляла собой просто двумерную таблицу с операциями упорядочения, выборки, проекции и соединения.

Перри сразу же понял, что разработчики System/38 строят очень похожую базу данных, за исключением того, что в ней нет соединения. Он позвонил Кодду, чтобы сообщить о работах в Рочестере и предложить свою поддержку. Но Кодд ответил, что, по его мнению, реляционные базы данных предназначены только для больших систем; а малым нужны только функции сортировки и слияния. По словам Перри, разговор не был сердечным. Тон Кодда он сравнил с тоном полицейских во время перекрестного допроса их защитниками на процессе О. Дж. Симпсона (O. J. Simpson) — вежливый, но холодный. Кодд и Тейлор больше никогда не разговаривали.

Через три года после объявления System/38 база данных System/R была объявлена как DB2 и признана в качестве первой реляционной базы данных[ 51 ]. Так как первоначально System/38 не поддерживала операции соединения, то она считается первой коммерческой базой данных с реляционными возможностями.

Двуликая база данных

Говоря о базе данных, мы имеем в виду не просто некоторое место для размещения данных. Мы говорим о системе управления базой данных. СУБД — среда для хранения и выборки данных, включающая определения данных, правила обеспечения их целостности и механизмы поддержания, а также операции сохранения и выборки данных. СУБД должна иметь интерфейс, чтобы пользователи могли работать с ней. В этом разделе мы представим два интерфейса СУБД AS/400: DDS (Data Description Specifications) и SQL (Structured Query Language), в следующих разделах — детально рассмотрим саму СУБД.

Когда IBM начинала проект System/38, стандартных интерфейсов к реляционной базе данных не существовало. Поэтому проектировщикам пришлось разработать собственный уникальный интерфейс для этой системы. Не удивительно, что этот интерфейс DDS очень похож на файловую систему, которую должен был заменить. Создатели интерфейса ограничились несколькими системными командами и функциями управления базой данных, а также ввели в MI команды для таких операций как чтение, запись, обновление и удаление. Программисты могли непосредственно использовать эти команды из таких языков как RPG и Cobol. Например, многие используют DDS-RPG: DDS для определений данных, RPG для доступа к ним. Интерфейс DDS перешел из System/38 в AS/400, и многие по-прежнему предпочитают его. Бывшим пользователям мэйнфреймов, перешедшим на AS/400, он также нравится, поскольку очень похож на интерфейс базы данных для больших систем IBM — IMS (Information Management System).

Примерно в то же время, когда разрабатывалась AS/400, в IBM и других фирмах выполнялись проекты по стандартизации SQL (из System/R) в качестве языка реляционных баз данных. Проект продвигался не слишком гладко, на создание стандарта потребовалось около десятилетия. Ingres многие годы использовала язык-соперник QUEL, пока, наконец, тоже не поддалась общей тенденции. Появившаяся в 1988 году AS/400 поддерживала и собственный интерфейс DDS, и SQL. Операторы SQL могут включаться непосредственно в программы на RPG, Cobol и С, заменяя «родные» команды, такие как чтение, запись и обновление. Для трансляции этих операторов SQL DB2/400 содержит прекомпиляторы.

При более внимательном взгляде становится видно, что DB2/400 состоит из двух отдельных частей. Собственно СУБД и язык DDS входят в состав OS/400. Query Manager and SQL Development Kit — особый продукт, приобретаемый отдельно. Как следует из названия, этот продукт содержит Query Manager — ПО AS/400 для конечного пользователя, позволяющее выдавать запросы на SQL. В состав продукта входят кроме того интерактивный пользовательский интерфейс к SQL (Interactive SQL), а также прекомпиляторы для различных языков, используемые при вставке операторов SQL в ЯВУ. К несчастью сложилось так, что IBM требует от Вас платить за SQL отдельно, тогда как DDS входит в состав OS/400. Такая ситуация — основная причина непопулярности SQL у многих пользователей AS/400, считающих его внешним продуктом, каковым он на самом деле не является. Сегодня большинство разработчиков баз данных в Рочестере думают в терминах SQL, а не DDS. Интерфейс DDS будет поддерживаться и далее, но новые функции, скорее всего, будут в SQL.

Хотя AS/400 и поддерживает два разных интерфейса к базе данных, крайне важно понимать, что сама база данных только одна. Доступ к данным, определение данных и манипуляции с ними на AS/400 возможны как посредством DDS, так и посредством SQL. Так как интерфейс SQL использует те же команды MI, что и DDS, каждый из интерфейсов может работать с объектами данных, созданных посредством другого интерфейса. Эта возможность смешения двух интерфейсов обеспечивает базе данных AS/400 дополнительные мощь и гибкость.

Самая большая проблема двух интерфейсов состоит в путанице, вызываемой терминологическими различиями. Как и в случае различий имен между объектами OS/ 400 и системными объектами MI, имена для разных интерфейсов базы данных подбирались разными группами. Например, в интерфейсе DDS имеются физические файлы, содержащие данные. Как мы видели ранее, физический файл — это двумерная таблица. В интерфейсе SQL тот же самый физический файл называется таблицей, что больше подходит для этой структуры. Логический файл в интерфейсе DDS не содержит данные, а указывает на реальные данные и дает программе некоторую их проекцию. В SQL логический файл называется проекцией (view). Аналогично, то, что в терминологии DDS — запись и поле, в интерфейсе SQL — строка и столбец (чтобы отразить концепцию таблицы).

Как функционирует база данных

В этом разделе мы рассмотрим различные компоненты базы данных AS/400. Я не ставил здесь перед собой задачу проинструктировать Вас, как использовать эту базу данных. Уже есть целый ряд хороших книг, посвященных внешним аспектам базы данных и использованию двух ее интерфейсов в программах[ 52 ]. А я лишь хочу предложить Вам обзор характеристик СУБД и основ ее функционирования.

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

Функции СУБД

Есть много способов реализации реляционной базы данных, но любая система управления ею должна предоставлять следующие семь функций:

определение и описание таблиц базы данных;

операции управления данными (вставка, выборка, обновление и удаление);

возможность определить, что представляют собой данные независимо от программы;

возможность создавать новые проекции данных для удовлетворения изменяющихся требований прикладных программ;

множественные проекции данных для разных прикладных программ;

защита данных;

целостность данных.

Теперь посмотрим, как эти функции реализованы в AS/400.

Описание данных и создание файлов

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

DDS позволяет определить несколько атрибутов полей записей базы данных. Среди них имя поля, его длина и род данных (текстовые или числовые). В зависимости от типа данных поля можно задать некоторые другие специфические атрибуты. Например, если поле содержит десятичные данные, можно задать общее число десятичных цифр и число цифр справа от запятой.

Операторы DDS помещаются в разделах исходных файлов, которые затем превращаются в файловые объекты с помощью команд OS/400 «CRTPF» («Create Physical File») и «CRTLF» («Create Logical File»). Для описания атрибутов файлов базы данных можно использовать и SQL. В отличие от DDS, представляющего собой только язык описания данных, один оператор SQL и описывает, и создает таблицы и проекции (view). В SQL определение файла неотделимо от команды создания. Например, оператор SQL «Create table» задает имя таблицы, имена столбцов (полей) и их атрибуты. Кроме того, при исполнении этого оператора создается и сама таблица.

Создание физических файлов и таблиц

Физические файлы или, в терминологии SQL, таблицы содержат собственно данные. Запись физического файла имеет фиксированный набор полей. Каждое поле может иметь (хотя и не часто) переменную длину. В терминологии SQL таблица содержит строки фиксированной длины со столбцами переменной длины[ 53 ].

Физический файл состоит из двух частей. В первой находятся атрибуты файла и описания полей. В набор атрибутов файла входят его имя, владелец, размер, число записей, ключевые поля и некоторые другие характеристики. Описания полей задают атрибуты для каждого поля записей.

Вторая часть физического файла содержит собственно данные. Она может состоять из одного или нескольких разделов, позволяющих подразделять файл. Все записи во всех разделах обязательно имеют один и тот же формат. Это удобный способ разделения записей: например, информацию текущего месяца можно поместить в один раздел, а информацию прошлого — в другой. Каждый раздел имеет уникальное имя, которое можно использовать для доступа к записям. Таблицы SQL могут состоять только из одного раздела, что соответствует самой сути реляционной модели: все данные хранятся в двумерных таблицах. Файлы же имеющие несколько разделов — трехмерные.

Для создания физического файла используется системная команда «CRTPF». Она создает физический файл по операторам из исходного файла. Вновь созданный физический файл не содержит записей данных, для их добавления необходимо использовать отдельную программу или утилиту.

Как было отмечено ранее, оператор определения данных SQL также создает таблицу. Оператор «Create table» можно выполнить с помощью Query Manager, Interactive SQL, или вставив его в программу на ЯВУ. Таблица, созданная этим оператором, является физическим файлом, идентичным созданному с помощью «родного» интерфейса.

Создание логических файлов и проекций

Логические файлы дают возможность доступа к данным в формате, отличном от использующегося для их хранения в одном или нескольких физических файлах. Логические файлы обеспечивают независимость данных и программ, которая будет обсуждаться в следующем разделе. Они не содержат записей данных, а лишь относительный номер записи (индекс) данных в физическом файле. Часто говорят, что логический файл задает путь доступа к данным.

Структура логического файла может быть как очень простой, так и очень сложной. Логические файлы и проекции можно подразделить на четыре категории. Перечислю их.

Простые логические файлы и проекции, которые отображают данные из одного физического файла или таблицы на другое описание логических записей.

Многоформатные логические файлы, обеспечивающие доступ к нескольким физическим файлам, каждый из которых имеет собственный формат записей. Данный тип логического файла может быть создан только с помощью «родного» интерфейса; с помощью SQL его создать нельзя.

Логические файлы объединения (join), задающие одно определение логической записи, построенное из любой комбинации полей двух или более физических файлов, таблиц, логических файлов или проекций. При этом общее число физических файлов и таблиц не должно превышать 32.

Проекции SQL (view), которые похожи на логические файлы объединения и дают те же результаты, но реализованы совершенно иначе. Файлы объединения хранят путь доступа для каждого объединения. Проекции же SQL определяют пути доступа во время исполнения, руководствуясь хранящимся внутри шаблоном определения запроса (Query Definition Template).

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

Для создания логического файла используется системная команда «CRTLF». Она использует операторы DDS в исходном файле для создания логического файла. Операторы DDS в исходном файле задают имена одного или нескольких физических файлов, служащих основой для логического. Созданный логический файл содержит относительные номера записей данных из одного или нескольких физических файлов.

Оператор SQL «Create view» задает таблицу, представляемую проекцией, вместе с описанием столбцов проекции. Результат создания проекции — логический файл, идентичный создаваемому при использовании «родного» интерфейса.

Логические файлы выполняют три операции: форматирование, включая проекцию, объединение и создание производных полей (field derivation); выборку записей; упорядочение. Логический файл, созданный с помощью DDS, может осуществлять все три операции. Файл, созданный с помощью SQL, может выполнять либо форматирование (проекция SQL), либо упорядочение (индекс SQL), но не обе сразу. На SQL нельзя создать проекций, выделяющих подмножество записей физического файла. Проекция SQL может быть создана с помощью DDS, но DDS обычно не используется для создания файлов, имеющих только возможности проекций SQL.

Словарь данных и каталоги

Описания компонентов всех физических и логических файлов содержатся на каждой AS/400 в одном месте. В терминах «родного» интерфейса это место называется словарем данных. Словарь данных — это специальный объект OS/400, который обслуживается менеджером базы данных и к которому могут обращаться пользователи для поиска информации о структуре и местах использования файлов. Менеджер базы данных автоматически обновляет информацию в словаре данных всякий раз при создании нового объекта СУБД.

Словарь данных позволяет разработчикам приложений и пользователям получить представление о структуре базы данных на любой системе. «Каковы форматы записей?», «Каковы атрибуты данных?», «Где в системе используется некое имя?», — с помощью словаря данных можно найти ответы на эти и другие вопросы.

В интерфейсе SQL словарь данных называется общесистемным каталогом. SQL также позволяет разработчикам создавать другие каталоги. Каждая коллекция (collection) SQL (библиотека в «нормальной» терминологии) может (хоть и необязательно) иметь собственный каталог.

Независимость данных и программ

Использование комбинации физических и логических файлов в AS/400 позволяет достичь независимости программ от используемых ими данных. Отделение описания данных от программ достигается тем, что прикладные программы рассматривают данные в формате, отличном от того в каком они хранятся физически. Концепция отделения программ и данных — одна из основ технологической независимости архитектуры System/38 и AS/400.

Рассмотрим структуру физического файла, содержащего помимо самих данных их описание, часто называемое внешним описанием файла. Как System/38, так и AS/ 400 имеют внешне описанные данные, которые не надо помещать в программу. Это означает, что программа не определяет, как данные должны физически храниться. Кроме того, одна прикладная программа может работать с файлами, содержащими данные в разных форматах.

Формат логического файла, так же как и формат физического — внешний, так что с помощью логических файлов можно переопределить формат записи программы. На рисунке 6.1 показан очень простой пример, иллюстрирующий некоторые функции логических файлов: использование программой логического файла для получения иного представления данных физического файла.

Рисунок 6.1. Независимость данных и программ

Обратите внимание на выделенные поля. Каждая запись физического файла содержит шесть полей; в то же время программа, посредством логического файла, «видит» только четыре из них. Возможность исключения полей из логического файла позволяет реализовывать защиту на уровне полей. Пользователи имеют доступ только к тем полям, которые им позволено видеть. Это лишь один прием защиты в AS/400. Более подробно тема защиты рассматривается в главе 7.

Другая функция, отображенная на рисунке — возможность переупорядочения полей записи. Порядок следования в логической записи полей общего дохода (gross) и федерального подоходного налога (FIT) изменен на обратный. Другими словами, программа независима от порядка следования полей.

Кроме того, рисунок 6.1 иллюстрирует переопределение полей записи. В физическом файле поле общего дохода представляет собой упакованное десятичное число, содержащее 7 цифр, две из которых расположены справа от запятой. Однако программа написана так, что поле общего дохода должно иметь зонный десятичный формат с 8 цифрами, две из которых расположены справа от запятой. Логический файл обеспечивает нужное программе представление, а также осуществляет преобразование между упакованным и зонным десятичным форматами.

Использование множественных логических файлов, построенных над одним и тем же физическим файлом, предоставляет альтернативные пути доступа к данным и обеспечивает разделение данных между программами. На рисунке 6.2 показан еще один логический файл для другой программы, который был добавлен к первому примеру. Теперь каждая программа имеет свое представление записей, хранящихся в физическом файле, и доступ только к тем полям, к которым он разрешен. Поля, присутствующие в обоих логических файлах, позволяют программам совместно использовать данные.

Рисунок 6.2. Совместное использование данных

Очень важно подчеркнуть, что обе программы работают с теми же самыми физическими данными, — копирования данных нет. Обновление данных, выполненное одной программой, становится немедленно «видимо» другой. Эта возможность работы программ с текущими значениями данных, а не с копиями, используется в System/38 и AS/400 на протяжении уже почти 20 лет.

Защита данных

Итак, логические файлы позволяют защищать данные на уровне записей и полей. Мы увидели на примере, что поля можно защитить, просто не включая их в описание логического файла. Рассмотренные нами примеры просты, и в них не показана возможность выборки записей. Достичь защиты на уровне поля можно с помощью выборки и пропуска на уровне логического файла. В результате, пользователи получат доступ только к данным, удовлетворяющим критериям выборки.

Если у пользователя нет доступа к какому-либо файлу, то данный файл защищен. Если пользователь, не имеющий прав на доступ, например, к общему доходу, попробует запустить программу, использующую данный путь, то программа не будет работать. Все логические и физические файлы AS/400 — это системные объекты, и для доступа к ним необходимы соответствующие права. Защита данных обеспечивается путем комбинации логических файлов и компонента управления доступом операционной системы.

Мы можем предоставить конкретному пользователю следующие виды доступа к какому-либо физическому файлу:

доступ ко всему файлу (с помощью средств управления доступом);

разрешить некоторые типы операций с файлом, например, чтение, но не обновление (с помощью средств управления доступом);

доступ к некоторым полям (с помощью логического файла);

доступ к некоторым записям (с помощью логического файла).

Целостность и восстановление данных

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

Средства восстановления данных необходимы на тот случай, если данные все же разрушатся или станут недоступными. Часто полагают, что такое может произойти лишь вследствие аппаратных сбоев. В AS/400 есть даже несколько средств предотвращения порчи данных при аппаратном сбое — это так называемые средства обеспечения доступности (availability). Но хотя аппаратный сбой — наиболее распространенная причина порчи данных, программы также могут содержать ошибки, после которых требуется восстановление данных.

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

Журнал

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

Ведение записей поддерживается двумя объектами OS/400: журналом и приемником журнала. Журнал идентифицирует журналируемые объекты, а приемник содержит записи журнала. Для гарантии сохранения информации приемники журнала могут немедленно записываться на диск.

Помимо прочего, запись журнала содержит следующую информацию: имена файла, библиотеки и программы, относительный номер записи, дату и время изменения; а также идентификацию задания, пользователя и рабочей станции. Вместе с этой информацией в приемник журнала записывается копия измененной записи. AS/400 может также записать в журнал копию записи перед выполнением изменения.

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

Системная защита пути доступа SMAPP

В прошлом пользователи AS/400 были вынуждены мириться с долгим временем перезагрузки после аварийной остановки: пути доступа[ 54 ], открытые для обновления файла, должны были быть построены заново. Вспомните, что в главе 5 мы упомянули возможность отложенной коррекции логического файла. Вследствие этого целостность логического файла при аварийной остановке может нарушиться. В зависимости от числа и размера открытых путей доступа по ключу, временной промежуток, требуемый для их восстановления, может быть значительным, для больших систем — несколько часов.

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

Для автоматического ведения журнала IBM разработала SMAPP (System-Managed Access Path Protection). Система сама вычисляет максимальное время, требуемое на восстановление путей доступа после сбоя и соответственно определяет необходимый объем журналирования путей доступа. Пользователь всегда может увеличить или уменьшить вычисленное системой время. Чем время меньше, тем больше системных ресурсов потребуется для ведения журнала. Таким образом, ведение журнала предполагает выбор между системными ресурсами, предназначенными для нормальной работы, и мерами предосторожности на случай аварийной перезагрузки.

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

SMAPP использует специальную область ведения журнала, не требующую действий со стороны пользователя. Эта область — циклическая, то есть по достижении конца запись продолжается с начала. Система всегда поддерживает в этой области достаточное число записей.

Управление транзакциями

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

Допустим, что необходимо одновременно изменить несколько взаимосвязанных записей. Часто, для описания такой ситуации используется пример с банкоматом. Пользователь банковского терминала запускает транзакцию: вставляет в машину кредитную карту, вводит идентификационный код и выбирает тип транзакции. В результате этого клиентская запись считывается из базы данных центрального компьютера, который может располагаться на другом конце города или земного шара. Если клиент запрашивает выдачу наличности, то по содержимому записи проверяется, достаточен ли остаток денег на счете. Затем остаток уменьшается на затребованную величину и банкомату посылается команда на выдачу денег. Что если случилась поломка, и банкомат не может выдать наличность? Прежде чем эта неудавшаяся транзакция завершится, следует отменить изменение остатка на счете клиента. Средство, используемое для этого в AS/400, — управление транзакциями (commitment control).

Так как все изменения невозможно выполнить одновременно, система обязана защитить группу взаимосвязанных записей и не освобождать ее до тех пор, пока все изменения не будут внесены. Команда «Commit» позволяет изменить группу записей так, чтобы она выглядела как одна операция. Если нельзя выполнить какое-либо изменение, то вся группа изменений может быть отменена по команде «Rollback». Для этих операций управление транзакциями использует журналирование.

Триггеры

Триггер — действие, выполняемое автоматически всякий раз, когда содержимое физического файла изменяется — удобный способ связать одну операцию с другой. Триггеры — разновидность пользовательского средства обеспечения целостности базы данных, встроенная в определение файла. Часто изменение базы данных, например, добавление или удаление записи, требует некоторых дополнительных действий. В этих случаях триггер может запустить соответствующую программу. В других случаях, при изменении записи может требоваться запустить программу проверки нового значения поля записи: например, если при обновлении данных в файле инвентарной описи число учитываемых предметов упадет ниже допустимого уровня. Триггер для такого файла может при каждом обновлении запускать программу, проверяющую значение и отправляющее поставщику в случае необходимости дополнительный заказ.

При добавлении к физическому файлу триггера необходимо определить три атрибута. Первый — событие, приводящее к запуску триггера: вставка, обновление или удаление записи из файла. Второй атрибут задает, когда следует запустить триггер — до или после события. Наконец, третий атрибут задает программу запуска триггера. Обычно это пользовательская программа, написанная на любом ЯВУ, поддерживаемом AS/400.

Таким образом, для каждого физического файла можно назначить до шести триггеров: по два триггера для обновления, вставки и удаления записей, так чтобы один триггер запускался до события, второй — после. Триггеры добавляют командой «ADDPFTRG» (Add Physical File Trigger), а удаляют командой «RMVPFTRG» (Remove Physical File Trigger).

Ссылочная целостность

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

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

В качестве простого примера предположим, что у нас имеется главный файл, содержащий запись для каждого клиента. В качестве ключа в этом файле используется ID клиента. Внутри базы данных имеются также другие файлы, использующие в качестве ключа ID клиента. В подобных случаях целесообразно, используя ссылочную целостность, ввести такое ограничение для каждого из зависимых файлов, которое не позволит прикладным программам добавлять в файлы ID клиента, если такого ID нет в главном файле. Очевидно, что могут быть и гораздо более сложные сценарии реализации ссылочной целостности.

Дисковые системы высокой доступности

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

Ранее мы рассматривали прямое восстановление базы данных с помощью журнала. Первым шагом этого процесса было восстановление резервной копии данных. Затем к этой копии применяются записи журнала, сделанные с момента ее создания, до тех пор, пока база данных не будет восстановлена.

У AS/400 мощные средства сохранения/восстановления. Но иногда для восстановления данных при сбое диска требуется неприемлемо большое время. Обычно, в процессе восстановления система недоступна пользователям. Это может доставить большие затруднения, особенно, если необходимо физически заменить диск перед восстановлением данных. Альтернатива такой процедуры — дисковая подсистема, которая может так переносить сбои диска, чтобы система не становилась недоступной. AS/400 поддерживает два типа защиты дисков для обеспечения высокой доступности: зеркалирование дисков и дисковые массивы.

Зеркалирование требует чтобы у каждого диска был «напарник». Всякий раз по команде записи на диск все данные дублируются на оба парных диска. Если один из дисков сломается, то доступ к данным со второго диска даст системе возможность продолжать работать. Для еще большей надежности диски в паре могут быть подключены к разным дисковым контроллерам, на разных процессорах ввода-вывода и на разных шинах. Путем подключения зеркальных дисков к оптической шине ввода-вывода их можно разместить даже в другом помещении (структура и взаимодействие компонентов ввода-вывода AS/400 описаны в главе 10). Зеркалирование обеспечивает наивысший уровень надежности, но дороговата, поскольку требует полного дублирования дисков.

Другой подход — использование дисковых массивов. В этом случае диски объединяются в наборы, и данные записываются на все диски набора. Сектор — это фиксированный блок данных на диске. Страница памяти обычно хранится в нескольких екторах диска, и операция записи распределяет сектора по всем дискам набора.

Добавление к массиву избыточного диска позволяет обнаруживать место сбоя и втоматически восстанавливать потерянную информацию. При этом используется перация <исключающего или> (XOR) над данными всех секторов набора . любой з операндов может быть восстановлен путем выполнения операции XOR над результатом и другим операндом. Данная технология известна как RAID (redundant arrays of nexpensive disks).

Пример операции XOR показан на рисунке 6.3. Результат операции . <истина> то есть, 1) . достигается тогда и только тогда, когда один из операндов <истина> (1), другой . <ложь> (0). В противном случае, если оба операнда являются <истиной> ли оба <ложью>, значением операции является <ложь> (то есть 0).

Рисунок 6.3. Пример операции исключающее ИЛИ

Операция XOR выполняется с данными соответствующих секторов на всех дисках, а ее результат операции сохраняется в секторе на избыточном диске. В случае сбоя диска, данные испорченного сектора восстанавливаются путем операции XOR над данными соответствующих секторов всех исправных дисков набора. Чтобы избежать перегрузки одного из дисков, контрольная информация (результаты операций XOR) распределяется на несколько дисков входящих в массив. Таким образом, любой диск содержит часть данных базы и часть результатов XOR.

Целостность данных, восстановление и надежность — важнейшие характеристики любой вычислительной системы. В этом разделе мы рассмотрели лишь основные аспекты этой поддержки.

Другие функции базы данных

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

Хранимые процедуры

Один из самых действенных способов повысить производительность клиент/серверных приложений для AS/400 — хранимые процедуры. Оператор CALL в SQL позволяет приложению вызывать хранимую процедуру, которая исполняется на сервере AS/400. Таким образом, в результате одного обращения к серверу выполняется це

лая транзакция. Без хранимых процедур для этого потребовалось бы множество таких обращений. В качестве хранимой процедуры может использоваться, за небольшими исключениями, любая программа AS/400, в том числе написанная на ЯВУ и даже содержащая операторы SQL. Доступ к хранимым процедурам возможен только через интерфейс SQL с использованием оператора CALL.

Поддержка национальных языков

Первый шаг в реализации Unicode на AS/400 был сделан в V3R1, где с его помощью кодировались имена объектов некоторых компонентов интегрированной файловой системы. Unicode поддерживает одновременное использование множества наборов символов (национальных алфавитов) в одной кодировке.

В RISC-моделях эта поддержка была расширена, чтобы обеспечить хранение в файлах базы данных в Unicode (UCS2, уровень 1). Например, в одном файле базы данных может находиться информация на французском, немецком, английском, иврите, китайском, русском и других языках. SQL поддерживает преобразование в Unicode и обратно, что делает возможным работу старых приложений с данными в этой кодировке. Кроме того, имеется поддержка локализации (locale) — стандарт X/Open, дающий программистам возможность создавать приложения, самостоятельно адаптирующиеся к различным национальным особенностям (символ денежной единицы, формат даты и времени, формат чисел, порядок сортировки, преобразование регистров символов и др.).

Предсказывающий регулятор запросов

В большинстве реляционных баз данных присутствует регулятор запросов (query governor) гарантирующий, что единичный запрос не будет выполняться слишком долго. По истечении заданного времени такой регулятор останавливает выполнение запроса.

DB2/400 же экономит системные ресурсы, используя предсказывающий регулятор запросов: если, выполнение запроса потребует столь много времени, что все равно будет прервано, то оно просто не начинается. Оптимизатор запросов предварительно анализирует способ, который будет применен при выполнении запроса для доступа к базе, и необходимое для этого время. Предсказанное время сравнивается с предельным временем запроса для данного пользователя. Если предсказанное время превосходит предельное, то пользователю посылается сообщение и тот может либо прекратить выполнение запроса, либо все-таки выдать запрос, отдавая себе отчет в том, что лимит будет исчерпан.

Повышение производительности базы данных

Для увеличения производительности различных операций в базе данных DB2/400 есть несколько механизмов. Например, команда «Explain» применяется для предсказания или просмотра характеристик исполнения запроса. Эта функция собирает информацию о том, как SQL используется в программе. Затем пользователь на основе полученной информации может вносить повышающие производительность изменения, как в базу данных, так и в сам запрос. Другие функции позволяют осуществлять операции выборки и вставки поблочно, то есть манипулировать массивами данных одной командой.

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

Распределенные базы данных

AS/400 позволяет прикладной программе работать с базой данных как на локальной, так и на удаленной системе; местоположение данных для приложения прозрачно. Это означает, что приложению доступна обработка файла базы данных без информации о том, где он находится. Кроме того, части базы данных могут быть перенесены на другую систему без изменения прикладных программ.

Возможность доступа к базе данных на удаленной системе и доступа удаленных систем к данным AS/400 достигается благодаря реализации двух ключевых архитектур: DRDA (Distributed Relational Database Architecture) и DDM (Distributed Data Management).

Для доступа к удаленным данным интерфейс SQL использует DRDA. Сначала устанавливается связь с удаленной базой при помощи оператора SQL CONNECT, в котором указывается имя базы. Для поиска имени удаленной базы данных и определения системы, на которой она расположена, используется справочник на локальной системе. После установки соединения между двумя системами возможна посылка запросов SQL к удаленной базе данных. Менеджер базы данных на удаленной системе отвечает на запрос и возвращает ответ на локальную систему.

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

Шлюзы к другим базам данных

AS/400 работает с базами данных, поддерживающими описанные архитектуры DRDA и DDМ, а также предоставляет интегрированный подход для доступа к другим базам данных. Это позволяет ей работать непосредственно с базой данных любого производителя на другом компьютере в сети. В дополнение к каталогу распределенной базы данных (Distributed Database Directory) в OS/400 присутствует менеджер драйверов (Distributed Database Driver Manager). Он работает с драйверами для других баз данных или файловых систем. Драйверы для баз данных Unix и ПК позволяют приложению AS/400 работать с этими базами так же, как и с любой базой DRDA.

Трансформация данных с помощью DataPropagator

Ранее, при обсуждении хранилищ данных мы упоминали о средствах трансформации данных, использующихся для их перемещения данных из оперативной базы в информационную. DataPropagator — одно из таких средств. Его можно использовать не только для хранилищ данных, но и для связи между любыми базами данных типа DB2.

В распределенной среде на разных компьютерах могут существовать множественные копии одного и того же файла базы данных. Изменение одной копии не отражается на другой немедленно, поэтому один и тот же файл на разных системах может быть в разной степени актуален. DataPropagator предоставляет механизм репликации изменений файла на все системы через некоторый, определяемый пользователем, интервал времени. Так как при этом используется технология репликации IBM, то изменения могут реплицироваться в сети на любую базу данных семейства DB2.

Соединение при помощи OptiConnect

Если компьютер работает не в сети, и сами данные, и средства их обработки располагаются на нем самом. Одиночная система AS/400 поддерживает очень большие, в том числе многопроцессорные, конфигурации, что вполне удовлетворяет нужды большинства крупных заказчиков. Однако, среди наших заказчиков есть такие, чьи требования к производительности и объемам данных превосходят возможности одиночной AS/400. Даже при работе компьютеров в сети накладные расходы на передачу данных ограничивают прирост производительности, который достигается путем распределения приложения между несколькими компьютерами. В этом случае может помочь OptiConnect. В главах 10 и 11 мы рассмотрим новейшие высокоскоростное межсистемное соединение — SAN. Но SAN поддерживается только линией AS/400е, так что OptiConnect еще будет какое-то время использоваться для объединения AS/400.

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

OptiConnect использует DDM, но здесь важно отметить следующее. DDM на сети применяет коммуникационные протоколы на линиях связи (ЛВС). При таком способе связи обычны сильные шумы, и коммуникационный протокол вставляет в передачу слои избыточности и проверок, что приводит к замедлению передачи. Оптическая шина обеспечивает соединение, достаточно чистое, чтобы устранить большую часть избыточности, в результате производительность существенно возрастает. При использовании OptiConnect время, необходимое для доступа к базе на удаленной системе увеличивается лишь на 3 миллисекунды по сравнению с временем доступа к локальной базе данных, то есть удаленные диски работают почти со скоростью локальных.

Рост производительности в результате разделения приложений и базы данных зависит от множества факторов, например, от степени использования базы данных. Однако то, что кластер OptiConnect может объединять до 32 машин, позволяет уверенно говорить, что с помощью этого соединения реально создание очень больших конфигураций.

OptiConnect применяется не только для наращивания. Система на волоконно-оптических линиях может заменить существующие ЛВС, использующие DDM, что сделает сетевые соединения более быстрыми и надежными. Соединение с помощью OptiConnect дублированных систем позволяет создавать конфигурации с высоким уровнем доступности и возможностей восстановления важнейших приложений и данных.

А теперь пришла пора спуститься на уровень ниже и рассмотреть, как функционирует база данных «изнутри». Затем мы поговорим об использовании машинного индекса для поддержки уже рассмотренных нами операций.

Внутренняя реализация функций базы данных

Как мы уже говорили в главе 3, функции базы данных AS/400 реализуются по разные стороны MI. В предыдущих разделах обсуждалась, в основном, база данных, реализованная как часть DB2/400 поверх MI. Давайте теперь рассмотрим некоторые системные объекты MI, используемые в DB2/400, а также то, как некоторые из операций над этими системными объектами реализованы в SLIC ниже MI. В этой книге нет места для детального описания всех средств и функций базы данных, и мы остановимся только на самых важных.

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

SLIC поддерживает большие базы данных. Приведем некоторые предельные величины:

до 240 ГБ на физический файл;

более 2 миллиардов записей на физический файл;

до 4 ГБ на индекс;

до 2048 байтов на ключ.

Следует отметить, что эти ограничения размеров связаны с текущей реализацией SLIC. Для MI нет какого-либо ограничения размеров системных объектов, так как он независим от технологии. SLIC же зависит от технологии, то есть размеры полей некоторых внутренних структур данных предопределены, что, в свою очередь, задает ограничения сверху. Мы обсудим некоторые из этих ограничений при рассмотрении внутренней реализации. Впрочем, как и в любой хорошей системе, здесь остается возможность модификаций, если таковые понадобятся, и об этом мы тоже поговорим.

А сейчас, начнем с рассмотрения системных объектов MI, поддерживающих базу данных.

Объекты базы данных

Ранее мы рассмотрели три основных системных объекта для поддержки базы данных: области данных, индексы областей данных и курсоры. Как и остальные системные объекты, они занимают несколько сегментов в одноуровневой памяти. Каждый из них имеет базовый сегмент, содержащий заголовок сегмента, заголовок ЕРА и специфический заголовок объекта; а кроме того — сегмент ассоциированного пространства.

Области данных

Области данных содержат записи базы данных. Все записи одной области данных схожи: однородны и имеют фиксированную длину. Записи хранятся в порядке их поступления, и все удаленные записи по-прежнему занимают место.

Объект «область данных» состоит из сегментов трех типов. Кроме базового сегмента и сегмента ассоциированного пространства, в его состав может входить до 120 сегментов записей области данных. Каждый элемент сегмента содержит байты состояния и записи базы данных. Байт состояния содержит информацию о нынешнем состоянии записи, или о том, была ли она удалена.

Каждая запись в сегменте области данных записей имеет номер, называемый порядковым номером. Порядковый номер задает положение записи в сегменте. Не путайте порядковые номера, отсчет которых начинается в каждом сегменте заново, с относительным номером записи (возможно, последний Вам лучше знаком, так как находится на уровне OS/400). Относительные номера записей, хранящиеся в логическом файле или проекции, указывают местоположение данных в физическом файле или таблице. Те же самые номера иногда называются в MI номерами элементов области данных.

Начинающийся с нуля порядковый номер указывает, является ли запись первой, второй или n-ной в сегменте. Так как длина всех записей одинакова, необходимости хранения в сегменте порядковых номеров нет. Зная порядковый номер и длину каждой записи можно найти стартовый байт любой записи сегмента. Далее будет рассказано, как порядковый номер используется для поиска записей в базе данных.

Базовый сегмент не содержит информации об области данных, его основная роль — хранить адреса сегментов области данных. Базовый сегмент также содержит адреса индексов, используемых с этой областью данных.

Ассоциированное пространство содержит таблицу описателей полей с описанием каждого поля записи. Там также размещается рабочая область, используемая компонентами базы данных OS/400. Например, в ассоциированном пространстве хранятся указатели на логические курсоры.

Индексы области данных

Индекс области данных задает альтернативный порядок записей в области данных. Для альтернативного упорядочения используется дерево с двоичным основанием. В разделе «Деревья с двоичным основанием» мы рассмотрим такое дерево и его использование для поддержки ряда функций AS/400, включая индекс области данных.

Индекс области данных задействован во множестве операций. Так, он поддерживает ключи переменной длины. Значения ключей могут вычисляться с помощью различных операций, таких как конкатенация, сложение, вычитание и умножение. Один такой индекс может обслуживать до 32 областей данных.

Есть несколько вариантов упорядочения индекса: по возрастанию, убыванию, числовому и абсолютному значениям. Существуют также варианты выполнения коррекции: обновления могут вноситься в индекс немедленно, либо быть отложены. Откладывание обновления индекса позволяет избежать накладных расходов, если изменение в области данных происходит, а индекс не используется.

В главе 5 были приведены примеры объектов, включая индекс области данных. Мы видели, что последний состоит из сегментов трех типов: базового, ассоциированного пространства и отложенной коррекции. Последние два сегмента уже были подробно рассмотрены, теперь остановимся на базовом сегменте.

Базовый сегмент содержит атрибуты альтернативной сортировки, обеспечиваемой индексом, а также таблицу, описывающую как индекс «видит» каждое поле записей в области данных. Это описание логического представления. Базовый сегмент также содержит до 32 адресов областей данных. Наконец, в базовом сегменте находится дерево с двоичным основанием.

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

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

Курсоры

Курсоры — механизм просмотра данных в области данных; через них осуществляется весь доступ к данным. Курсор, о котором мы сейчас говорим, — системный объект MI. DB2/400 поддерживает позиционируемые (scrollable) и последовательные файловые курсоры в соответствии со стандартом SQL 1992. Курсор SQL — это не то же самое, что и системный объект MI «курсор», хотя последний и используется для реализации первого.

Как уже упоминалось, записи физического файла хранятся внутри разделов. Физический файл может состоять из одного или нескольких разделов. Это удобный способ разделения на части данных внутри физического файла. Логические файлы используют ту же концепцию множества разделов. Мы также оговорили, что таблицы и проекции SQL ограничены одним разделом на таблицу или проекцию.

Курсор связан с каждым разделом файла. Он может обеспечить доступ к записям области данных как в порядке их поступления, так и в порядке ключей индекса. Другими словами, курсор может указывать на область данных либо непосредственно, либо «сквозь» индекс области данных. Один курсор может использоваться для нескольких областей данных, а для одной области — несколько курсоров. Курсор отслеживает текущее положение в пути доступа, принадлежащем программе (или заданию, или группе активации). Кстати, это помогает понять, почему он так называется.

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

Курсор позволяет осуществлять выборку записей, используя для этого функции арифметического и строкового проецирования. Обычно, критерий выборки записей задается в предложении WHERE оператора SQL (в DDS использовать арифметические выражения нельзя). С помощью курсоров (то есть, путей доступа), которые выбирают лишь некоторые записи, можно предотвратить нежелательный просмотр пользователем остальных записей. Иными словами, курсор обеспечивает защиту базы данных.

Курсор состоит из двух сегментов: базового и ассоциированного пространства. Базовый сегмент содержит два набора адресов для указания областей данных и индексов областей данных, которые могут использоваться курсором; и тех и других может быть по 32. Единственный случай, когда может потребоваться более одного индекса области данных — логический файл объединения (join-logical file, а не проекция SQL). Базовый сегмент также содержит код проецирования и код выборки, используемые курсором. Ассоциированное пространство курсора содержит текст описания раздела и его атрибуты. Связи на уровне раздела поддерживаются компонентом базы данных в OS/400.

Теперь, изучив каждый из трех основных системных объектов поддержки базы данных, можно говорить о том, как пользователь обращается к файлам базы данных в AS/400.

Доступ пользователя к данным

Все пути доступа пользователя к базе данных идут через OS/400 и MI, прямой доступ к данным — только у SLIC. С точки зрения пользователя, доступ к файлу базы данных OS/400 осуществляется с помощью открытия файла. На уровне MI эта функция реализована командой «Activate cursor». Когда пользователь закрывает файл, аналогично используется команда MI «Deactivate cursor».

При доступе к области данных пользователь может задать несколько опций команды открытия файла. В их состав входят тип операции (чтение, запись, обновление и удаление) и число записей. Если курсор оперирует с несколькими областями данных, пользователь может отобрать для работы подмножество этих областей. Определение этого подмножества задается при создании файла командой «CRTLF». В процессе работы это подмножество может быть переопределено командой «OVRDBF» (Override with Database File), выданной перед открытием файла. При создании файла пользователь также может задать время ожидания заблокированной записи, и также переопределить это время перед открытием файла.

Пользователь осуществляет доступ к области данных в произвольном или последовательном режиме. В режиме последовательного доступа возможна пересылка нескольких страниц с диска в основную память операцией переноса (bring). Пользователь задает размер переноса с помощью опции «число записей» в команде «OVRDBF» или «OPNQRYF» (Open Query File). В режиме произвольного доступа обычно считы-вается одна страница. Произвольный режим возможен только в том случае, если у области данных есть индекс, тогда код базы в SLIC использует схему просмотра для переноса в память следующей логической страницы индекса.

Для доступа к данным в области данных нужен курсор. Поэтому для начала работы можно использовать команду MI открытия курсора «Activate cursor», а по завершении закрыть курсор командой «Deactivate cursor». Эти функции работы с курсором на уровне MI эквивалентны открытию и закрытию файла в OS/400. Ассоциированное пространство активного курсора содержит информацию об открытом пути данных ODP (Open Data Path) для открытого раздела.

Исполнение команды: MI «Activate cursor» присоединеняет курсор к активизировавшему его процессу (единица работы в системе), а точнее — к связанному с процессом блоку управления (этот объект MI будет подробно рассмотрен позднее). Если процесс активизирует более одного курсора, то к блоку управления процессом присоединяется двусвязный список курсоров. Теперь никакой другой процесс не сможет использовать эти курсоры. Если тот же самый курсор потребуется другим пользователям, то при активизации ими курсора будет создана его копия.

Получается, что курсор может быть постоянным и временным. Постоянный курсор связан с каждым разделом файла, а каждый раздел файла имеет один и только один постоянный курсор. Если курсор активизируется для предоставления ODP к разделу файла, но он уже был активизирован другим процессом, то создается временный курсор-копия. В целях экономии места коды проецирования и выборки во временном курсоре не хранятся. Адреса во временном курсоре указывают на постоянный курсор, содержащий соответствующие коды.

По принятому соглашению, OS/400 всегда создает временную копию постоянного курсора с помощью команды «CRTDUPOBJ» (Create Duplicate Object) и затем активизирует только временные курсоры. Благодаря этому, постоянный курсор может быть представлением раздела файла, так как помимо него объекта-раздела на уровне MI нет. Более того, все ODP — это временные курсоры, что также результат соглашений принятых в OS/400, а не ограничение MI.

Журналы SLIC

Ранее мы рассматривали ведение журналов базы данных. Базовые функции для протоколирования изменений базы данных реализованы ниже MI. Соответствующая поддержка предоставляется двумя системными объектами MI: порт журнала и область журнала. Порт журнала управляет определением журнала, а область журнала представляет собой контейнер для записей в него. Эти два объекта поддерживают объекты OS/400 журнал и приемник журнала соответственно. Обратите внимание, что на границе MI имена снова меняются.

Порт журнала, как и почти все другие системные объекты, состоит из двух сегментов. Базовый сегмент содержит адреса объектов, для которых ведется журнал, а также адреса текущих журнальных пространств. Компонент базы данных, реализованный в OS/400, использует сегмент ассоциированного пространства.

Область журнала — это специальный системный объект MI, состоящий из множества сегментов. Базовый сегмент содержит адреса порта журнала, а также адреса до 120 сегментов данных журнала. Сегмент данных журнала — это сегмент еще одного типа, который может быть частью системного объекта «область журнала». В сегментах данных журнала хранятся записи журнала.

Записи журнала имеют переменную длину. Каждая запись содержит: поле длины, последовательный номер, поле типа, отметки времени и даты, идентификацию пользователя, программы и задания, а также информацию, заносимую в журнал. Важно отметить, что эти записи не могут обновляться или удаляться. Задачей журнала является просто хранение копий изменений базы данных на тот случай, если потребуется восстановление.

Управление транзакциями в SLIC

Ранее мы обсуждали базовые функции подтверждения и отката изменений. Эти функции поддерживаются и в MI, и в компоненте базы данных на уровне SLIC. В MI такую поддержку предоставляет системный объект блок транзакции (commit block). Он фиксирует изменения объекта, участвующего в транзакции. Блоки транзакции связаны с процессами.

Объекты добавляются к блоку транзакции и удаляются из него. Блок транзакции также содержит информацию о блокировках записей. Эти блокировки освобождаются командой MI <<Cornrnrt>>. Команда <<Decornrnrt>>, которая практически во всех ЯВУ (включая набор команд OS/400) называется «Rollback», откатывает все изменения, сделанные в процессе транзакции, освобождает блокировки и устанавливает курсор в положение, нормальное на момент начала транзакции.

Машинные индексы

Перейдем к последней теме, связанной с нижним уровнем поддержки базы данных в AS/400 — к индексам. Мы уже обсуждали два вида индексов: независимый (в главе 5) и индекс области данных (в этой главе). Повторю, что оба этих системных объекта содержат дерево с двоичным основанием.

Итак, что такое индекс? На мой взгляд, наиболее удачное определение таково: индекс — организованный набор информации для быстрого поиска в наборе элементов, например в большой таблице. Индексация играет важную роль в реализации многих компонентов AS/400 и любой другой системы. Поэтому еще при проектировании System/38 было принято решение встроить ниже MI максимально эффективный индекс таким образом, чтобы все системные компоненты могли при необходимости использовать его, а не создавать свои собственные. Этот встроенный индекс и называется машинным индексом.

Машинный индекс полезен различным компонентам AS/400 при поиске в таблицах, адресации областей, сортировке и т. д. База данных применяет его при индексации области данных, работе со списком транзакций журнала и т. п.; компонент управление памятью — для многих своих справочников. Машинные индексы используются и в контекстах, и для поиска прав доступа. OS/400 использует объекты типа «независимый индекс» для нескольких целей, включая обработку сообщений, защиту

и спулинг.

Основные характеристики машинного индекса таковы:

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

управляет используемым пространством;

позволяет минимизировать случаи отсутствия нужной страницы в памяти (страничные ошибки);

поддерживает ключи переменной длины до 2048 байтов;

использует алгоритм двоичного поиска;

хранит элементы в виде фрагментированного дерева с двоичным основанием (подробнее — в разделе «Внутренняя организация дерева с двоичным основанием» этой главы).

Двоичный поиск

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

Прием быстрого угадывания чисел в этой игре основан на двоичной системе счисления. Чтобы угадать число между 1 и 1000, при первой попытке следует назвать 512 (29 = 512). Если нам скажут, что это число слишком велико, то задуманное число больше нуля и меньше 512, поэтому далее мы называем 256 (28= 256) — следующую меньшую степень двойки. Если же сказано, что названное число меньше задуманного, то задумано число большее 512 и для следующей попытки нужно прибавить 256 к 512 и назвать 768, и при каждой следующей попытке прибавлять следующую меньшую степень двойки. Если названное число больше задуманного, мы вычитаем эту степень двойки и прибавляем следующую меньшую степень.

Предположим, что первый игрок задумал 700. Отгадывающему следует называть такую последовательность чисел: 512, 768, 640, 704, 672, 688, 696 и, наконец, 700. При этом ему будет сообщаться, что первое число меньше, второе больше, третье меньше и т. д. На основании этой информации он будет вычислять следующее значение и, в конце концов, задуманное число будет отгадано за восемь попыток.

Если мы посмотрим на последовательность ответов первого «больше/меньше» из приведенного примера, то заметим интересную закономерность. Эта последовательность выглядит так: «меньше», «больше», «меньше», «больше», «меньше», «меньше», «меньше» и «равно». Если на место каждого ответа «больше» подставить 0, а на место каждого ответа «меньше» — 1, то мы получим двоичное число. Учитывая, что для задания любого числа между 1 и 1000 требуется 10 разрядов, можно представить 700 как 1010111100. Мы угадали это число, двигаясь слева направо и используя ответы «больше/меньше» для определения двоичной цифры в текущей позиции.

С использованием данного метода задуманное число всегда может быть найдено не более чем за 10 попыток. В нашем примере потребовалось только восемь попыток,так как число делится на 4 — степень двойки. Обратите внимание, что любое нечетное число потребует 10 попыток, по одной на разряд. Максимальное число попыток можно вычислить как логарифм 1000 по основанию 2. Иначе это значение можно определить, учитывая, что 2 = 1024. Для угадывания числа между единицей и миллионом по данному методу требуется лишь 20 или менее попыток. Приведенный пример иллюстрирует алгоритм двоичного поиска, который применяется для нахождения элемента индекса.

Структура, в которой все записи заполнены, считается сбалансированной. При поиске по сбалансированному индексу с n элементами требуется выполнить сравнение лишь для log2 n элементов. Наш пример с угадыванием чисел был сбалансированным, так как в последовательности присутствуют все числа. Но даже для сильно несбалансированных структур среднее число попыток возрастает менее чем на 10 процентов. Алгоритм двоичного поиска отлично работает для большого числа элементов, но обычно не рекомендуется, если их число меньше 50.

Деревья с двоичным основанием

Описанный выше метод двоичного поиска можно представить в виде древовидной структуры. Дерево будет содержать два типа узлов: тестовые и окончательные. Каждый тестовый узел дерева проверяет один разряд числа. По тому, равен разряд 1 или 0, в качестве следующего выбирается один из двух узлов следующего уровня. Начиная с вершины дерева[ 55 ], первый узел проверяет первый разряд числа (самый левый). Второй слой дерева содержит два текстовых узла, один из которых выбирается, если первый разряд был равен 0, а другой — если первый разряд был равен 1. На третьем уровне имеется четыре узла, на четвертом — восемь и так далее вплоть до десятого узла, на котором расположено 512 тестовых узлов. Одиннадцатый уровень — последний для данного дерева и содержит 1024 окончательных узла. Окончательный узел содержит точное значение искомого числа.

Итак, для поиска числа мы начинаем с вершины дерева и проверяем разряды: слева направо. На каждом уровне дерева проверяется один из разрядов. После десяти проверок мы оказываемся в одном из окончательных узлов и можем точно назвать число.

Мы только что описали двоичное дерево. Оно сбалансированное, так как присутствуют все узлы. При поиске по таблице могут присутствовать не все узлы, так как в таблице присутствуют не все возможные элементы. Следовательно, и проверяются не все разряды числа, некоторые уровни могут отсутствовать. Такое дерево в отличии от двоичного дерева, где присутствуют все узлы, называется деревом с двоичным основанием (binaryradix tree).

Использование деревьев с двоичным основанием в AS/400 для реализации машинных индексов мы рассмотрим на примере рисунка 6.4. На нем показан простой файл из девяти записей, упорядоченных в порядке поступления. Каждая запись имеет несколько полей, на рисунке показаны лишь некоторые. Одно из полей — поле имени — предназначено для использования в качестве ключа. Для файла построен индекс, который также показан на рисунке. Каждая запись индекса имеет только два поля: поле ключа и логический адрес записи. Девять элементов индекса отсортированы по порядку значений ключа. В данном случае, ключи отсортированы по алфавиту, и первым элементом является Baker, а последним Wu. Поле логического адреса записи задает относительную позицию соответствующей записи в исходном файле, логическая адресация всегда начинается с 0 (для первой записи). Элемент для Baker указывает, что запись Baker является в файле седьмой.

	Файл		Индекс
					Адрес
Имя	Дата рождения	Должность		Имя	логической записи 0
JONES	082140	A		BAKER	006
SMITH	122750	K		BARNS	007
WU	041259	Z		CARSON	008
MARKLY	111163	T		JOHNSON	005
PETERS	070457	C		JONES	000
JOHNSON	062753	A		MARKLY	003