Може комп'ютерна книга залишатися актуальною через 30 років після написання?

Недавній черговий пост на тему «Як прочитати 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 сторінок, і сподіваюся вона буде цікава всім, хто цікавиться історією комп'ютерів і ОС.

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

Приємного читання!
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.