Недавний очередной пост на тему «Как прочитать 100 книг за год, и достичь успеха в жизни» заставил меня вспомнить, какие же книги на самом деле изменили мой взгляд на жизнь. Ну ладно, пусть не на жизнь, а хотя бы на программирование, для начала.

И припомнилась мне при этом старая-престарая по меркам программирования книга под завлекающим названием «Что мама никогда не рассказывала вам о сопровождении VM». В оригинале она называется «What Mother Never Told You about VM Service», автор Melinda W. Varian.

Итак, на минутку, это 1983 год. Только что появилась первая версия MS DOS. Появления CVS еще ждать примерно 8 лет. Unix уже существует, но пока не получил распространения (у нас в Москве он появится в виде Демос примерно в 1986 на машинах СМ-4). Большинство компьютерных книг того времени сегодня безнадежно устарели.

Книга предназначалась для системных программистов — тех, кто занимался сопровождением системы VM (известной также как CP 67, VM/370, VM/SP, VM/ESA и под многими другими названиями).

Казалось бы, может ли такая книга быть интересной сегодняшним админам (пожалуй, это лучшее соответствие для той деятельности, которая тогда называлась системным программированием)? Посмотрим, судите сами.

Итак, книга посвящается тому, как нужно генерировать ядро, применять полученные от IBM обновления и багфиксы, делать бэкапы, и многому другому.

Оказывается, еще и так можно?

Первое, что изменило тогда мои взгляды на программирование — это способ внесения изменений в код ядра. Сегодня мы назвали бы это патч. В принципе, утилита IEBUPDTE была мне известна уже давно, со времен OS/360, и синтаксис с самих патчей для утилиты UPDATE в CMS был очень похожий. Отличие состояло в том, что сами патчи умел генерировать текстовый редактор XEDIT. Вместо изменения оригинального файла он создавал патчи, которые затем применялись при помощи UPDATE.

Сам процесс генерации ядра упрощенно выглядел так — берем дистрибутив, состоявший из исходных текстов ядра на ассемблере S/370, скомпилированных объектных файлов (часть исходников не поставлялась), макробиблиотек, применяем к ядру патчи по списку из так называемого CONTROL файла, далее ассемблер, линкер, и запись ядра на диск.

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

В принципе, ничего сложного.

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

Конечно же, UPDATE (даже вместе с XEDIT) — это не Git. Более того, это даже не CVS. Это примерно соответствует по возможностям RCS, которая впрочем, появилась примерно в это же время. Но это было одно из первых применений версионирования кода, которое мне встретилось на практике.

Правила выживания системного программиста

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

Опустим технические детали, и приведем только список правил, которым автор рекомендует следовать:

1. NEVER CHANGE ANYTHING IBM SENDS YOU — никогда не меняйте то, что вам прислали из IBM
2. KEEP YOUR STUFF SEPARATE FROM IBM’S — храните ваши файлы отдельно от файлов IBM
3. DON’T EXPECT IT TO WORK — не рассчитывайте на то, что это заработает
4. ALWAYS LEAVE TRACKS — оставляйте следы изменений
5. VM SYSTEM PROGRAMMERS DO IT VIRTUALLY ALL THE TIME — вы можете проверить новую систему в любое время
6. BACK IT UP — делайте бэкапы
7. BACK IT UP AGAIN — делайте бэкапы снова
8. DON’T TRUST DDR — не доверяйте DDR
9. CHECK THE UNRESOLVED REFERENCES — проверьте неразрешенные ссылки
10. PLAN ON BACKING IT OUT — планируйте бэкапы
11. YOU ARE ENTITLED TO A HOME TERMINAL — вам полагается свой (домашний) терминал
12. CHANGE ONLY ONE THING AT A TIME — меняйте только что-то одно за раз
13. YOU CAN NEVER HAVE TOO MANY S-DISKS S-дисков не бывает слишком много

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

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

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

Остальные пункты очевидны без пояснений.

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

А тогда и подавно, для нашей команды системных программистов эта книга была обязательной к прочтению, и практически настольной, наравне с обычной документацией по VM. Кстати, на форумах для системных программистов z/OS эту книжку до сих пор советуют. Были даже планы выпустить новую, отражающую реалии VM/390.

Не буду дальше пересказывать. Если вам интересна компьютерная история — лучше почитайте сами.

Книга доступна в PDF в интернете, на сайте самой Мелинды. Сохранено оригинальное форматирование, выполненное под существовавшие тогда принтеры.

В ней примерно 120 страниц, и надеюсь она будет интересна всем, кто интересуется историей компьютеров и ОС.

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

Приятного чтения!
ссылка на оригинал статьи https://habrahabr.ru/post/314758/