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

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

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

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

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

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

В прошлом ядро каждой ОС было уникальным, мало кто брался разрабатывать ядро отдельно от ОС. Однако в середине 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. В 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 получила новое дыхание.