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 успішною, а уроки, отримані в ході цього, стали фундаментом сучасних підходів у розробці ПЗ.

Продовження слід