IBM System/360 — История о провале, не оказавшимся таковым
Я продолжаю мой цикл статей про IBM System/360 (первая часть о системе «в целом», вторая часть про архитектуру). Не затронутыми осталось несколько интересных тем, и первая из них — это операционные системы System/360, особенно исторический аспект их развития.До начала 60-х годов, «мощные» и «бюджетные» решения IBM были несовместимы. Перенос программ был затруднен, а порою и совсем невозможен. Это обуславливалось многими причинами, начиная с разницы в операционных системах, и заканчивая различиями периферии. То, что сейчас кажется само собой очевидным — совместимость различных программных и аппаратных компонентов, тогда было совсем не обязательным. Именно в ходе разработки System/360 инженеры компании решили, что такой подход сильно удорожает разработку и дальнейшее сопровождение, и решили стандартизировать новую систему, упростив портирование программ и сопровождение ЭВМ.
Изначально планировалось поставлять компьютеры System/360 с новой операционной системой с пакетной обработкой заданий. Проще говоря, каждая программа, которую надо запустить, описывается в виде «пакета» — самой программы и набора входных данных. Эти пакеты обрабатываются последовательно в зависимости от приоритета и наличия ресурсов. Такой подход позволял уменьшить человеческое участие в планировании работы мейнфрейма и оптимизировать его загрузку, снижая таким образом накладные расходы. Операционная система должна была называться OS/360.
Разработчики этой ОС поставили перед собой невероятно амбициозные задачи, которые не решались до этого. Данная операционная система должна была обеспечить поддержку «многопрограммности». С медленной периферией исполнение только одной программы за раз приводило к частым простоям, когда система ждала каких-то данных с внешнего устройства. Поэтому использовался подход, схожий с современным асинхронным программированием. В память загружалось несколько программ и первая из них запускалась на выполнение. При необходимости долгого ожидания, контекст текущей программы сохранялся, и управление передавалось следующей, которая могла работать, пока первая ждала данные. Операционная система в этом случае должна была держать все под постоянным контролем, защищая загруженные программы от сбоев других программ, и контролируя доступ к ресурсам. Все это усложнялось отсутствием концепции виртуальной памяти. Операционная система должна была работать на всех моделях линейки, поэтому конфигурации разнились от 16 КБ ОЗУ и до 1 МБ, а скорость работы — от нескольких тысяч операций в секунду, до полумиллиона. Так же операционная система должна была удовлетворять потребности всех программ, начиная со сложных математических расчётов, почти не использовавших внешние накопители, и заканчивая простыми аналогами СУБД, которые полностью строились на операциях ввода-вывода.
Как видите, планы были амбициозными, но поджимало время. Аппаратная часть была готова поступить в продажу, конкуренты атаковали сегменты рынка, в которых IBM была наиболее уязвима, а стабильная и надежная версия OS/360 никак не рождалась. Кроме того, получающееся решение никак не хотело вмещаться в память младших моделей. Было принято соломоново решение выпускать операционную систему в более простом виде с обещанием дальнейших апгрейдов.
Были разработаны несколько промежуточных вариантов.
BOS/360 (Basic OS) — система для самых простых младших моделей.
TOS/360 (Tape OS) — система для модификаций с загрузкой с магнитной ленты.
DOS/360 (несмотря на название, не имела ничего общего со знакомыми нам DOS эпохи x86) — «основная» версия для большинства средних и мощных конфигураций.
PCP (Primary Control Program) — то, что в наше время назвали бы «бета-версией» полной OS/360, не поддерживавшая многопрограммность.
К выходу Series/360–67 (если вы читали первую часть статьи, то должны помнить, что в этой системе появилась концепция виртуальной памяти) планировался релиз TSS/360 (Time Sharing System). Как понятно из названия, эта версия должна была поддерживать режим с разделением времени. Пробные версии этой операционной системы были отданы на тестирование крупным корпоративным клиентам, но отзывы были негативными, да и ОС уже «опоздала» с учетом ситуации на рынке, поэтому выход TSS/360 был отменен. К этому времени уже была достаточно отлажена ОС CP-67, которую разрабатывали в Кембриджском Исследовательском Центре IBM. CP-67 была стабильна настолько, что IBM стала ее предоставлять клиентам, правда на условиях «отказа от гарантии», как ОС с поддержкой разделения времени. Дальнейшее развитие этой операционной системы привело к тому, что она легла в основу VM/370 и потом z/VM.
»
Проблемы, с которыми IBM столкнулись при разработке OS/360, были настолько велики, что дали толчок становлению «software engineering», в том виде, в котором мы его знаем. Именно тогда стало понятно, что разработка ПО и управление этим процессов — это ресурсоемкие дисциплины, к которым нужно применять научный подход для получения контролируемого результата.
Старший менеджер проекта разработки OS/360, на которого была возложена личная ответственность за все, написал книгу, ставшую практически библией для менеджеров разработки ПО (как говорил автор — «все ее читали, но никто ей не следует»). Да, речь о Фредерике Бруксе и его книге «Мифический человеко-месяц».
Из всех принципов, которые Брукс сформулировал, наиболее четко характеризуют суть проекта по разработке OS/360 следующие два.
Добавление ресурсов (в том числе и человеческих) на проект не всегда приводит к сокращению его сроков, часто эффект может быть даже обратным. Как сказано в книге, разработка компилятора Алгол — всегда занимает полгода, независимо от числа задействованных программистов.
Новая версия успешной системы зачастую обречена на провал, так как разработчики будут пытаться реализовать все пожелания пользователей. Брукс называл это «эффектом второй системы».
Как видите, с одной стороны разработка основной версии OS/360 если и не стала полным провалом, то весьма к нему приблизилась. С другой стороны, в IBM сумели, несмотря на это, сделать System/360 успешной, а уроки, полученные в ходе этого, стали фундаментом современных подходов в разработке ПО.
Продолжение следует
