VMS / OpenVMS — kronika systemu, który nie chciał umrzeć

Historia operacyjnego systemu, który wyprzedził epokę o dekady, w ukryciu wychował Windowsa, został pogrzebany przez korporacyjne fuzje — i wstał z grobu na procesorze, którego za życia nie znał.

Inne komputery padały. Ten po prostu trwał. Administrator, który go uruchomił, zdążył się zwolnić, ożenić i awansować gdzie indziej, a maszyna wciąż przyjmowała loginy. W społeczności VMS-a uptime liczony w latach był powodem do dumy, nie do paniki — udokumentowano klastry działające bez przerwy siedemnaście lat.

Spis treści

  1. Wprowadzenie: dlaczego warto znać system, którego nigdy nie widziałeś
  2. Narodziny (1975–1978)
  3. Filozofia i powłoka DCL
  4. Architektura od środka
  5. System plików, który pamiętał wszystko
  6. Klaster: niezniszczalność jako cecha projektowa
  7. VMS kontra reszta świata (Unix, Linux, DOS, Windows)
  8. Czas hakerów
  9. Skąd się wziął POSIX i jak zmienił VMS-a
  10. Zemsta Cutlera: jak VMS został Windowsem
  11. Trzy przeprowadzki: VAX → Alpha → Itanium
  12. Śmierć (powolna i przez korporacyjne ręce)
  13. Zmartwychwstanie (2014 →)
  14. Epilog
  15. Ciekawostki zebrane
  16. Oś czasu
  17. Źródła i dalsze lektury

1. Wprowadzenie: dlaczego warto znać system, którego nigdy nie widziałeś

Jeśli nie pracowałeś w banku, na giełdzie, w fabryce, szpitalu albo instytucji rządowej z długą pamięcią, prawdopodobnie nigdy nie widziałeś działającego OpenVMS-a na oczy. A mimo to dotykasz jego dziedzictwa codziennie — bo fundament każdego współczesnego Windowsa to w prostej linii intelektualne dziecko VMS-a, zaprojektowane przez tego samego człowieka.

VMS to system, który warto poznać z trzech powodów. Po pierwsze, był laboratorium pomysłów, które reszta branży „odkrywała” dziesięć, dwadzieścia, trzydzieści lat później: wersjonowanie plików, klastry wysokiej dostępności, rozproszone blokowanie zasobów, listy kontroli dostępu. Po drugie, jego historia to gotowy scenariusz na film — z hakerami sprzedającymi sekrety KGB, robakiem protestującym przeciw broni jądrowej i korporacyjnym dramatem o zdradzie, ucieczce i procesie. Po trzecie, to jedno z nielicznych pełnych studiów przypadku tego, jak doskonała technologia może przegrać nie z lepszą technologią, lecz z decyzjami zarządów i logiką rynku — a potem, wbrew wszystkiemu, wrócić do życia.

Ten tekst jest pomyślany jako rozdział książki: można go czytać linearnie jak opowieść, ale każdy rozdział stoi też o własnych siłach jako notatka merytoryczna. Daty i fakty są opatrzone źródłami na końcu.

2. Narodziny (1975–1978)

Na początku był problem inżynierski. W kwietniu 1975 roku Digital Equipment Corporation (DEC) — wówczas druga firma komputerowa świata, ustępująca tylko IBM — rozpoczęła projekt 32-bitowego rozszerzenia swojej legendarnej, 16-bitowej linii minikomputerów PDP-11. Architektura 16-bitowa dusiła się w ciasnocie adresowej; klienci potrzebowali większej przestrzeni pamięci i mocy. Odpowiedzią był VAX — Virtual Address eXtension — a jego pierwszym wcieleniem maszyna VAX-11/780, ogłoszona 25 października 1977 roku.

VAX-11/780 stał się czymś więcej niż produktem — stał się jednostką miary. Jego wydajność, około jednego miliona instrukcji na sekundę, przyjęto w branży za punkt odniesienia: „1 VUP” (VAX Unit of Performance). Przez lata moc innych komputerów podawano w wielokrotnościach tej jednej, konkretnej maszyny spod Bostonu.

Sprzęt potrzebował systemu operacyjnego. Tym systemem był VMS — Virtual Memory System. Pierwsza pełna wersja, V1.0, ukazała się w 1978 roku. Architektura systemu wyrastała wprost z doświadczeń zespołu przy systemie RSX-11M na PDP-11, i to dziedzictwo widać w dziesiątkach konwencji — od sposobu zarządzania procesami po filozofię niezawodności.

Głównymi architektami byli trzej ludzie: Dave Cutler, Dick Hustvedt i Peter Lipman. To Cutler nadał systemowi charakter. Inżynier o bezkompromisowym, niemal wojskowym podejściu do dyscypliny kodu, słynął z otwartej niechęci do Uniksa — uważał go za niespójny zlepek złożony przez zbyt wiele rąk bez jednej nadrzędnej wizji. Z tej niechęci wyrósł cały etos VMS-a: jeden spójny projekt, w którym kompletność i niezawodność stoją ponad elegancją minimalizmu, a słowo „reboot” jest przyznaniem się do porażki. Ta postać wróci do naszej opowieści w najmniej oczekiwanym miejscu — po drugiej stronie barykady, w Microsoftcie.

💡 Ciekawostka. Terminal VT100 firmy DEC, towarzyszący maszynom VAX, do tego stopnia zdominował rynek, że jego sekwencje sterujące stały się faktycznym standardem. Gdy dziś otwierasz „terminal” na Linuksie czy macOS, twój emulator najczęściej deklaruje się jako kompatybilny z vt100 albo xterm. Duch DEC-a siedzi w każdej konsoli.

3. Filozofia i powłoka DCL

Pierwsze spotkanie z VMS-em wyglądało tak:

          Welcome to VAX/VMS Version V4.7

Username: ANDERSON
Password:

          Welcome to VAX/VMS Version V4.7

    Last interactive login on Tuesday,  3-MAR-1987 09:12:47.06
    Last non-interactive login on Monday,  2-MAR-1987 23:58:01.55

$

Ten skromny znak zachęty $ to DCL — Digital Command Language — powłoka i język skryptowy VMS-a. I to właśnie tu najszybciej czuć różnicę filozofii w stosunku do Uniksa. Tam, gdzie Unix mówił lakonicznie ls, cp, rm, VMS mówił pełnymi słowami: DIRECTORY, COPY, DELETE, SET DEFAULT. Każde polecenie można było skrócić do unikalnego przedrostka (DIR, SET DEF), ale domyślny ton był jasny: kod ma być czytelny dla człowieka, który przyjdzie po tobie — najpewniej o trzeciej w nocy, gdy coś się zepsuje.

DCL miał spójną, samodokumentującą się składnię opartą na kwalifikatorach z ukośnikiem:

$ DIRECTORY/SIZE/DATE/OWNER [ANDERSON.PROJEKT]
$ COPY/LOG raport.txt raport_kopia.txt
$ PRINT/QUEUE=LASER/COPIES=3 umowa.txt
$ SET DEFAULT DKA0:[ANDERSON.PROJEKT]
$ HELP COPY

Dwa filary elastyczności DCL to symbole (odpowiednik zmiennych) i nazwy logiczne (logical names). Te drugie to jeden z najsprytniejszych pomysłów systemu: warstwa pośrednia między nazwą a fizycznym zasobem. Nazwa logiczna mogła wskazywać dysk, katalog, urządzenie, plik, a nawet inną nazwę logiczną — coś pomiędzy zmienną środowiskową a montowaniem, tylko bardziej systemowe i wszechobecne.

$ DEFINE BAZA DKA1:[PRODUKCJA.DANE]
$ DEFINE/SYSTEM RAPORTY DKA2:[WSPOLNE.RAPORTY]
$ TYPE BAZA:klienci.dat
$ SHOW LOGICAL BAZA
   "BAZA" = "DKA1:[PRODUKCJA.DANE]" (LNM$PROCESS_TABLE)

Dzięki temu aplikacja nigdy nie musiała znać twardych ścieżek. Przenosisz dane na inny dysk? Zmieniasz jedną definicję, a setki programów dalej działają. To rozwiązanie, do którego świat uniksowy dochodził później przez dowiązania symboliczne i zmienne środowiskowe — tu było wpisane w rdzeń systemu od początku.

4. Architektura od środka

Pod przyjazną powłoką krył się system zaprojektowany z chirurgiczną dbałością o izolację błędów i synchronizację. Najważniejsze decyzje architektoniczne VMS-a opierały się wprost na sprzętowych możliwościach procesora VAX — i to one tłumaczą, dlaczego ten system był tak stabilny.

Cztery tryby dostępu

Procesor VAX oferował cztery sprzętowe tryby uprzywilejowania, a VMS wykorzystywał je wszystkie — w odróżnieniu od Uniksa i większości późniejszych systemów, które obywały się dwoma (jądro i użytkownik):

Każdy tryb miał własny stos, a każda strona pamięci mogła mieć ochronę określoną osobno dla każdego z trybów. Awaria w warstwie wyższej nie musiała pociągać za sobą całości — drobnoziarnista izolacja, której większość systemów wtedy nie miała. Co istotne, te cztery poziomy okażą się później kłopotem przy przenoszeniu VMS-a na nowoczesne procesory, które udostępniają tylko dwa użyteczne — ale o tym w rozdziale 13.

Przerwania, AST-y i synchronizacja

VAX miał 32 poziomy priorytetu przerwań (IPL), które VMS wykorzystywał do precyzyjnej synchronizacji w jądrze. Dla aplikacji kluczowym mechanizmem były AST-y (Asynchronous System Traps) — sprzętowo wspierane wywołania zwrotne, dzięki którym proces mógł zostać powiadomiony o zdarzeniu (np. zakończeniu operacji wejścia-wyjścia) bez aktywnego czekania. To fundament asynchronicznego I/O, które VMS miał elegancko rozwiązane dekady przed modnym dziś „async/await”.

Wejście-wyjście i komunikacja międzyprocesowa

Sercem operacji wejścia-wyjścia była usługa systemowa $QIO (Queue I/O), pozwalająca zlecać operacje synchronicznie lub asynchronicznie. Procesy komunikowały się i synchronizowały za pomocą flag zdarzeń (event flags), skrzynek pocztowych (mailboxes — wirtualnych urządzeń do przekazywania komunikatów) oraz globalnych sekcji pamięci współdzielonej. To był bogaty, spójny zestaw prymitywów systemowych — znów kontrast z uniksową filozofią „złóż sobie sam z prostych klocków”.

VAX: triumf złożoności (CISC)

Architektura VAX była skrajnym przykładem podejścia CISC — Complex Instruction Set Computing. Miała pojedyncze instrukcje robiące rzeczy, które gdzie indziej wymagały całych procedur: obliczanie wielomianu, formatowanie tekstu z polami, operacje na kolejkach, liczenie sum kontrolnych. Idea była szlachetna: zbliżyć język maszynowy do języków wysokiego poziomu. W praktyce ta złożoność stała się ciężarem, a branża skręciła ku prostocie RISC. Gdy DEC projektował następcę VAX-a — procesor Alpha — świadomie odrzucił całą tę barokową złożoność na rzecz minimalistycznego, szybkiego rdzenia. To zderzenie filozofii (bogactwo VAX-a kontra ascetyzm Alphy) jest jednym z najciekawszych wątków technicznych w całej historii i, jak zobaczymy, wymusiło sprytne sztuczki przy każdej kolejnej przeprowadzce systemu.

5. System plików, który pamiętał wszystko

Tu mieści się funkcja, która do dziś wywołuje u weteranów westchnienia tęsknoty. System plików VMS-a, Files-11 (struktury dyskowe ODS-2, później ODS-5), miał wbudowane wersjonowanie. Zapis nie nadpisywał pliku — tworzył jego nową wersję, oznaczoną kolejnym numerem po średniku.

$ DIRECTORY

Directory DKA0:[ANDERSON.PROJEKT]

LOGIN.COM;3         RAPORT.TXT;7        RAPORT.TXT;6        RAPORT.TXT;5
MAIL.MAI;1          NOTATKI.TXT;12      BUDZET.DAT;2        BUDZET.DAT;1

Total of 8 files.
$

Widać RAPORT.TXT w wersjach 7, 6 i 5 jednocześnie. Pomyłkowo zapisałeś bzdury na ważnym pliku? Poprzednia wersja wciąż istnieje — wystarczy odwołać się do niej numerem. Sprzątanie starych wersji było czynnością świadomą (PURGE), a limit przechowywanych wersji ustawiało się per plik lub katalog (SET FILE/VERSION_LIMIT). Pełna specyfikacja pliku w VMS była zresztą małym dziełem sztuki, kodując w jednym ciągu węzeł sieci, dysk, hierarchię katalogów, nazwę, typ i wersję:

WEZEL::DYSK:[KATALOG.PODKATALOG]NAZWA.TYP;WERSJA
BOSTON::DKA0:[ANDERSON.PROJEKT]RAPORT.TXT;7

W odróżnieniu od uniksowego pliku-jako-strumienia-bajtów, pliki VMS-a były strukturalne dzięki warstwie RMS (Record Management Services), wbudowanej w sam system. RMS rozumiał rekordy o stałej i zmiennej długości oraz pliki indeksowane (ISAM) z wyszukiwaniem po kluczach — bez angażowania osobnej bazy danych. Dla aplikacji biznesowych (księgowość, ewidencja, bankowość) był to ogromny komfort; dla unixowca przyzwyczajonego do cat i grep — kulturowy szok.

Bezpieczeństwo: tożsamość, przywileje, ACL

Tożsamości i uprawnienia trzymał plik SYSUAF.DAT (System User Authorization File), którym zarządzało się narzędziem AUTHORIZE. VMS miał drobnoziarnisty model przywilejów (np. SYSPRV, BYPASS, CMKRNL) zamiast uniksowego „wszystko albo nic” roota, a także listy kontroli dostępu (ACL) i identyfikatory praw — znów dekady przed tym, zanim stały się standardem gdzie indziej. Konto administracyjne nazywało się SYSTEM; istniało też serwisowe konto FIELD dla techników DEC. Te dwa konta, jak zobaczymy w rozdziale o hakerach, były piętą achillesową niejednej instalacji.

6. Klaster: niezniszczalność jako cecha projektowa

Jeśli jedna funkcja miałaby zdefiniować VMS-a, byłoby to klastrowanie — i to nie doklejone później, lecz przemyślane jako fundament dostępności.

DEC ogłosił VAXcluster w maju 1983 roku, a wsparcie weszło do systemu wraz z VMS V4 w 1984. Idea była radykalna: wiele fizycznych maszyn, z których każda uruchamia własną kopię systemu, prezentuje się światu jako jeden system (single system image) — ze wspólną pamięcią dyskową, wspólnymi kolejkami zadań i wydruków oraz wspólną domeną bezpieczeństwa. Węzły mogły dołączać i odłączać się od klastra bez zakłócania reszty.

Mechanizmem, który to spinał, był rozproszony menedżer blokad (Distributed Lock Manager, DLM), zaprojektowany przez Steve'a Beckhardta i wydany w 1984 z VAX/VMS V4.0 (jednowęzłowa synchronizacja istniała już w V3.0 z 1982). DLM pozwalał wielu węzłom bezpiecznie współdzielić te same dyski, a nawet te same pliki, z blokowaniem na poziomie pojedynczego rekordu. To rzadkość: większość klastrów oferowała dostęp „albo ja, albo ty”; VAXcluster dawał przezroczysty, w pełni rozproszony zapis i odczyt z blokadą rekordową.

Pierwsze klastry wymagały specjalnego sprzętu — interconnectu CI (Computer Interconnect) z pasywnym Star Couplerem i kontrolerami pamięci masowej HSC. W 1986 roku DEC dodał LAVc (Local Area VAXcluster) działający po zwykłym Ethernecie, co otworzyło klastrowanie dla tańszych maszyn MicroVAX i pozwoliło uruchamiać bezdyskowe węzły-satelity bootujące przez sieć. Z czasem doszły kolejne nośniki (DSSI, SCSI, FDDI, Memory Channel, Gigabit Ethernet), a w OpenVMS V8.4 (2010) — klastrowanie po TCP/IP, co umożliwiło rozciąganie klastra na duże odległości geograficzne i budowę konfiguracji odpornych na katastrofy.

$ SHOW CLUSTER

View of Cluster from system ID 1024  node: BOSTON   14-MAR-1995 11:42:18

+--------------------------------------+
| SYSTEMS          |     MEMBERS       |
|------------------+-------------------|
| NODE     SOFTWARE| STATUS    VOTES   |
|------------------+-------------------|
| BOSTON   VMS V6.1| MEMBER       1    |
| QUINCY   VMS V6.1| MEMBER       1    |
| SALEM    VMS V6.1| MEMBER       1    |
+--------------------------------------+

Klaster obsługiwał do 96 węzłów i — co niezwykłe — pozwalał na konfiguracje mieszane architektonicznie: w jednym klastrze mogły współistnieć maszyny VAX i Alpha albo Alpha i Itanium. To była błogosławiona własność podczas migracji: stary i nowy sprzęt pracowały ramię w ramię, a usługę przenosiło się stopniowo, nie gasząc jej ani na chwilę. Stąd właśnie biorą się legendarne uptime'y liczone w latach — bo aktualizacja systemu czy wymiana sprzętu nie oznaczała przerwy, lecz „przepięcie” obciążenia na inny węzeł klastra.

Warto dodać, że VMS dorobił się też wczesnego, dojrzałego SMP (przetwarzania symetrycznego na wielu procesorach) już w wersji V5.2 z 1988 roku.

💡 Ciekawostka. Cała branża „odkryła” wysoką dostępność i klastry pod hasłem high availability w latach 90. i 2000. VMS robił to produkcyjnie, z blokowaniem rekordowym i pojedynczym obrazem systemu, od 1984 roku.

7. VMS kontra reszta świata (Unix, Linux, DOS, Windows)

Charakter VMS-a najlepiej widać w zderzeniu z konkurencją. Każdy z tych systemów był ucieleśnieniem innej filozofii informatyki.

Unix (i jego potomek Linux) wyrastał z laboratoriów Bell Labs i głosił ascetyczne wyznanie: małe narzędzia, które robią jedną rzecz dobrze, i komponuj z nich resztę. Plik to strumień bajtów, uprawnienia są proste, jądro robi minimum. Elegancja, elastyczność i przenośność za cenę tego, że spójne, kompletne usługi musisz sobie poskładać sam.

VMS głosił dokładnie odwrotne wyznanie: dam ci kompletne, dopracowane, niezawodne usługi, żebyś nie musiał ich składać. Strukturalne pliki, bogate prymitywy, klastry w standardzie, drobnoziarniste bezpieczeństwo. Kompletność i niezawodność za cenę większej masy i mniejszej zwięzłości.

DOS grał w zupełnie innej lidze — minimalistyczny, jednozadaniowy system dla domowych pecetów, bez ochrony pamięci i bez prawdziwej wielozadaniowości. Windows do wersji 3.x był jedynie graficzną nakładką na DOS. Dopiero Windows NT — o czym osobny, dramatyczny rozdział — wprowadził do świata Microsoftu prawdziwy, chroniony, wielozadaniowy system. I zrobił to, czerpiąc garściami z VMS-a.

Cecha VMS / OpenVMS Unix / Linux DOS Windows (NT+)
Filozofia jeden spójny projekt, niezawodność ponad wszystko małe narzędzia, kompozycja minimalizm na PC GUI + kompatybilność wsteczna
Powłoka DCL (pełne słowa) sh / bash (zwięzła) COMMAND.COM cmd / PowerShell
Pliki strukturalne (RMS) + wersjonowanie strumień bajtów strumień bajtów strumień bajtów
Tryby CPU 4 pierścienie 2 brak ochrony 2
Bezpieczeństwo przywileje + ACL (wcześnie) uprawnienia rwx, później ACL brak ACL (model NT)
Klastrowanie natywne od 1984, blokada rekordowa doklejane warstwy brak doklejane później
Rodowód własna linia (z RSX-11) własna linia (Bell Labs) QDOS / CP/M dziecko VMS-a

8. Czas hakerów

W latach 80. i wczesnych 90. sieci akademickie, wojskowe i korporacyjne stały w dużej mierze na VAX-ach z VMS-em, spiętych protokołem DECnet — który był tak głęboko zintegrowany z systemem, że zdalne logowanie czy dostęp do plików na innym węźle (SET HOST) były równie naturalne jak praca lokalna. A tam, gdzie stoją ciekawe maszyny pełne ciekawych danych, prędzej czy później pojawiają się ciekawscy ludzie. Dwie historie z tej epoki przeszły do legendy.

Kukułcze jajo (1986)

Bohaterem jest Clifford Stoll — astronom, który po utracie grantu trafił do działu komputerowego Lawrence Berkeley National Laboratory (LBNL) w Kalifornii. W 1986 roku przełożony zlecił mu wyjaśnienie błahostki: rozbieżności na 75 centów w rozliczeniu czasu komputerowego. Okazało się, że to dziewięć sekund pracy systemu zużyte przez konto, które za nie nie zapłaciło — bo nie powinno istnieć.

Zamiast zaksięgować różnicę i zapomnieć, Stoll pociągnął za nitkę. Odkrył intruza, który zdobył uprawnienia administratora, wykorzystując dziurę w funkcji movemail programu GNU Emacs — „podłożył jajo” w cudzym systemie, niczym tytułowa kukułka podrzucająca jajo do obcego gniazda. Włamywacz nie zatrzymywał się w Berkeley; używał laboratorium jako odskoczni do sieci wojskowej MILNET, polując na pliki ze słowami „nuclear”, „SDI” (reaganowska Inicjatywa Obrony Strategicznej) czy „stealth”.

Stoll rozpoczął samotne, miesięczne polowanie. Zwoził do laboratorium dziesiątki terminali i drukarek (pożyczanych z biurek nieobecnych kolegów), by rejestrować każdy ruch intruza, sypiał w biurze, bo włamywacz logował się nocą. Ślad telekomunikacyjny prowadził przez sieć Tymnet i kontraktora obronnego MITRE, a ostatecznie — z pomocą niemieckiej poczty (Bundespost) — do Hanoweru w RFN.

By zatrzymać włamywacza wystarczająco długo do namierzenia, Stoll zastawił pułapkę, która przeszła do podręczników jako jeden z pierwszych honeypotów w historii: wymyślił fikcyjny dział „SDInet” z fałszywą sekretarką „Barbarą Sherwin” i zapełnił go górnolotnie brzmiącymi, lecz bezwartościowymi dokumentami. Włamywacz połknął przynętę.

Tropem był Markus Hess, który wraz ze wspólnikami (m.in. Dirk Brzezinski i Peter Carl, w orbicie niemieckiego Chaos Computer Clubu kręcili się też hakerzy o pseudonimach Pengo — Hans Hübner — i Hagbard — Karl Koch) sprzedawał wykradzione dane radzieckiemu KGB. Szacuje się, że Hess włamał się do około 400 amerykańskich systemów wojskowych, a grupa zarobiła na tym około 54 000 dolarów. Stoll opisał śledztwo w fachowym artykule „Stalking the Wily Hacker” (Communications of the ACM) i w bestsellerowej książce The Cuckoo's Egg (1989); historię sportretował też dokument PBS NOVA „The KGB, the Computer, and Me” (3 października 1990).

💡 Ciekawostka — i przestroga, która nie zestarzała się ani trochę. Stoll był zdumiony, jak łatwo intruz wchodził na maszyny o wysokim rygorze bezpieczeństwa, w tym wojskowe: administratorzy nagminnie nie zmieniali fabrycznych haseł domyślnych, a na niektórych systemach dało się zalogować jako guest bez żadnego hasła. Trzydzieści kilka lat później to wciąż jeden z najczęstszych wektorów włamań.

Robak WANK (1989)

16 października 1989 roku, kilka dni przed startem wahadłowca z sondą Galileo na pokładzie, na ekranach systemów VMS w sieci SPAN (NASA Space Physics Analysis Network) oraz w sieciach Departamentu Energii USA zaczął pojawiać się komunikat:

  W O R M S    A G A I N S T    N U C L E A R    K I L L E R S
 ______________________________________________________________

            Your System Has Been Officially WANKed

To był WANK — Worms Against Nuclear Killers — pierwszy poważny robak komputerowy z jawnym przesłaniem politycznym. Sonda Galileo zasilana była plutonowymi generatorami radioizotopowymi, co — trzy lata po katastrofie Challengera i w cieniu zimnej wojny — wywołało protesty ruchów antynuklearnych pod Centrum Kosmicznym Kennedy'ego. Robak był cyfrowym przedłużeniem tego protestu.

Napisany w całości w DCL, WANK rozprzestrzeniał się po DECnecie, wykorzystując te same słabości, które tropił Stoll: konta, w których nazwa użytkownika była zarazem hasłem, konta bez hasła oraz konta systemowe. Miał na sztywno zakodowaną listę około stu typowych nazw użytkowników VAX-a. Symulował kasowanie plików (siejąc panikę), choć w istocie nie niszczył danych. Dwa tygodnie później pojawił się jego poprawiony wariant, OILZ, łatający część błędów oryginału.

Odpowiedź obrońców była elegancka: John McMahon (NASA) i Kevin Oberman (DOE) napisali program „anti-WANK”, który wykorzystywał mechanizm samokontroli robaka — ten przed infekcją sprawdzał, czy w tablicy procesów nie ma już jego kopii. Anti-WANK podszywał się pod tę kopię, więc robak „uznawał”, że system jest już zajęty, i sam się wycofywał.

Autorów nigdy oficjalnie nie wskazano. Najczęściej wymienia się dwóch hakerów z Melbourne o pseudonimach Electron i Phoenix, a w kodzie znaleziono nawiązania do australijskiego, antynuklearnego zespołu Midnight Oil. Najbardziej poetycki dowód australijskiego śladu: robak celowo omijał strefę 48 DECnetu — czyli Nową Zelandię, która ogłosiła się krajem wolnym od broni jądrowej. „Tam już zrozumieli”, zdawał się mówić kod.

💡 Ciekawostka. Historię WANK-a spisali później australijska dziennikarka Suelette Dreyfus i — jako badacz — Julian Assange w książce Underground. Tak, ten sam Assange, wiele lat przed WikiLeaks. Świat hakerów bywa zaskakująco mały.

9. Skąd się wziął POSIX i jak zmienił VMS-a

Ten wątek nie jest historią VMS-a — to historia, która VMS-a dopadła.

Problem narastał przez całe lata 80.: Unix, zamiast pozostać jednym systemem, rozmnożył się w dziesiątki niezgodnych ze sobą wariantów (System V, BSD, SunOS, HP-UX, AIX, Xenix i inne). Program napisany pod jeden nie chciał się kompilować pod drugim. Dla największego pojedynczego nabywcy komputerów na świecie — rządu USA — był to kosztowny absurd i pułapka uzależnienia od dostawcy.

Rozwiązaniem miała być standaryzacja. Pod egidą IEEE powstał projekt (rozpoczęty około 1984 roku), którego owocem była norma IEEE Std 1003.1-1988 — wspólny, „neutralny wobec producenta” interfejs systemowy wzorowany na Uniksie. Program zgodny z normą miał dać się przenosić między systemami.

Norma potrzebowała chwytliwej nazwy. Komitet ochrzcił ją roboczo „IEEE-IX” (czy „IEEEIX”), co Richardowi Stallmanowi — twórcy projektu GNU — zdecydowanie się nie spodobało. Jak sam wspominał, „IEEEIX” wymawiałoby się jak okrzyk przerażenia, więc obawiał się, że ludzie i tak będą mówić po prostu „Unix” — a to wzmocniłoby AT&T, rynkowego rywala GNU. Stallman wziął więc inicjały od „Portable Operating System” i dokleił uniksowy sufiks „-ix”. Tak powstał POSIX: Portable Operating System Interface. Komitet uznał nazwę za łatwiejszą do wymówienia i zapamiętania — i ją przyjął.

Sednem dla losów VMS-a był jednak ruch administracyjny: rząd USA przekuł POSIX w wymóg zakupowy poprzez federalny standard FIPS 151-1. W praktyce oznaczało to brutalne: jeśli twój system nie jest zgodny z POSIX, wypadasz z przetargów rządowych.

Dla DEC-a był to problem egzystencjalny. VMS był wszystkim — tylko nie Uniksem. Odpowiedź była dwutorowa: do systemu dodano warstwę zgodności POSIX (uniksowe interfejsy i narzędzia), a sam system około 1991–1992 roku przemianowano z „VAX/VMS” na „OpenVMS” (nazwa pojawiła się po wersji V5.4-2), by podkreślić otwartość na standardy. Przy okazji odcięto słowo „VAX”, bo trwał właśnie port na nową architekturę Alpha.

💡 Ciekawostka — najczęstsze nieporozumienie. „Open” w OpenVMS nigdy nie znaczyło „open source”. Znaczyło „otwarty na otwarte standardy (POSIX, Unix)”. System był i pozostaje własnościowy (z domieszką komponentów open source). To tak częsty błąd, że twórcy musieli go prostować przez dekady.

Ironia tej historii jest pełna: POSIX — narzędzie ujednolicania rozbujanego świata Uniksa — pośrednio zmusił najbardziej „nie-uniksowy” system rynku do założenia uniksowego kostiumu. Tradycja trwa do dziś: współczesny OpenVMS na x86 oferuje środowisko GNV (żartobliwie: GNU's Not VMS) z powłoką bash i narzędziami GNU dla deweloperów przyzwyczajonych do Uniksa.

10. Zemsta Cutlera: jak VMS został Windowsem

To najbardziej zaskakujący zwrot akcji w całej opowieści — i najlepszy dowód, że idee nie umierają tam, gdzie się rodzą.

Cofnijmy się do końca lat 80. DEC pracował nad nową, ambitną architekturą RISC o kryptonimie Prism i pisanym pod nią systemem Mica, projektowanym jako następca VMS-a. Szefem tych prac był Dave Cutler. W 1988 roku zarząd DEC anulował Prism (stawiając na inne plany), a Cutler — sfrustrowany utratą swojego dzieła — w październiku 1988 odszedł do Microsoftu, zabierając ze sobą znaczną część zespołu inżynierów.

Po drugiej stronie czekał Bill Gates, który szukał kogoś, kto zbuduje poważny system operacyjny — nie graficzną nakładkę na DOS-ie, lecz prawdziwy, chroniony, wielozadaniowy i przenośny OS. (Kontakt skojarzył podobno Nathan Myhrvold.) Cutler dostał ten projekt. Powstał z niego Windows NT (New Technology), który zadebiutował w 1993 roku i stał się fundamentem całej późniejszej linii: Windows 2000, XP, 7, 10, 11 oraz wszystkich edycji Windows Server.

I tu robi się gorąco. NT odziedziczył po linii VMS/Mica zaskakująco wiele: warstwową architekturę z trybami jądra i użytkownika, menedżer obiektów, drobnoziarniste przywileje i ACL, asynchroniczne wejście-wyjście, struktury i pomysły rozpoznawalne dla każdego, kto znał VMS-a. Sam Cutler był głównym architektem obu systemów, a podobieństwa wielokrotnie zauważano — branżowcy mówili wręcz o „efekcie Cutlera”.

Inżynierowie DEC dostrzegli te zbieżności i uznali, że przeszczepiono know-how (a być może i kod) z projektu Mica. DEC zagroził pozwem o własność intelektualną. Sprawa zakończyła się ugodą: Microsoft zapłacił DEC-owi (źródła podają kwoty od około 100 do 180 milionów dolarów, najczęściej wymienia się około 150 mln) i zobowiązał się wspierać architekturę Alpha w Windows NT. Oficjalnie ubrano to w język współpracy i szkoleń — ale w branży nikt nie miał złudzeń, czego ta ugoda naprawdę dotyczyła.

A na deser anegdota, którą fani powtarzają od lat. Weź litery V, M, S i przesuń każdą o jedną w alfabecie:

V → W
M → N
S → T
-----------
VMS  →  WNT   (Windows NT)

To dokładnie ten sam dowcip, co HAL → IBM z 2001: Odysei kosmicznej. I tak jak Arthur C. Clarke oraz Stanley Kubrick zaprzeczali, że HAL był celowy, tak Cutler zaprzeczał intencjonalności WNT. Oficjalnie to „ciekawy zbieg okoliczności”. Technicznie jednak wniosek pozostaje: za każdym razem, gdy uruchamiasz Windowsa, dotykasz ducha systemu zaprojektowanego w DEC-u w latach 70.

💡 Ciekawostka. Cutler nie zatrzymał się na NT. Później pracował nad przeniesieniem Windows na 64-bitową architekturę AMD64 (x86-64) — tę samą, na której dziś działa odrodzony OpenVMS — a jeszcze później przy platformie Azure i konsoli Xbox. Jeden architekt zostawił ślad w trzech epokach informatyki.

11. Trzy przeprowadzki: VAX → Alpha → Itanium

Większość systemów operacyjnych jest przywiązana do jednej architektury procesora i ginie razem z nią. VMS przeżył trzy wielkie przeprowadzki — inżynierski wyczyn, który sam w sobie zasługuje na rozdział.

VAX → Alpha (lata 90.)

Gdy CISC-owa złożoność VAX-a stała się hamulcem, DEC zaprojektował czystą, 64-bitową architekturę RISC o nazwie Alpha. Port VMS-a wykonano, biorąc „migawkę” kodu VAX-a z okolic wersji V5.4-2 i tworząc na jej bazie osobne, w pełni 64-bitowe drzewo źródeł (zarządzane narzędziem VDE). Wiele zależności sprzętowych VAX-a przeniesiono do firmware'u Alphy (SRM) oraz do mikrokodu PALcode — to właśnie PALcode emulował charakterystyczne mechanizmy VAX-a, w tym cztery tryby dostępu, na nowym sprzęcie. Aby ułatwić migrację klientom, udostępniono translator binarny VEST, tłumaczący stare pliki wykonywalne VAX-a na Alphę bez dostępu do kodu źródłowego. W 1994 roku, wraz z OpenVMS V6.1, osiągnięto „funkcjonalną równoważność” wersji VAX i Alpha.

Alpha → Itanium (2001–2005)

W 2001 roku — tuż przed przejęciem przez HP — Compaq ogłosił port OpenVMS na intelowską architekturę Itanium (IA-64), będący konsekwencją decyzji o porzuceniu rozwoju Alphy. Tym razem nie tworzono osobnego drzewa źródeł: Itanium budowano ze wspólnej bazy kodu z Alphą, dodając kod warunkowy tam, gdzie różniła się platforma. Pierwsze uruchomienie nastąpiło 31 stycznia 2003 roku — minimalny system wystartował na stacji HP i2000, zalogował się jako SYSTEM i wykonał polecenie DIRECTORY (ten skromny rytuał „pierwszego DIR-a” powtórzy się przy każdej kolejnej przeprowadzce). Wersje przedprodukcyjne V8.0 i V8.1 ukazały się w 2003, a pierwsze produkcyjne wydanie, V8.2, w lutym 2005 (dostępne także dla Alphy). Dla zgodności udostępniono translator AEST, tłumaczący pliki Alphy (a nawet wcześniej przełożone z VAX-a) na Itanium.

💡 Ciekawostka. Decyzja, by przedprodukcyjne wersje portu na Alphę numerować jako „V1.x”, narobiła zamieszania wśród klientów — i nie powtórzono jej przy Itanium. Drobiazg, ale pokazuje, jak bardzo numeracja wersji potrafi mieszać ludziom w głowach.

12. Śmierć (powolna i przez korporacyjne ręce)

VMS nie zginął od jednego ciosu ani od konkurencji technicznej. Zginął od łańcucha przejęć i strategicznych decyzji, z których żadna nie była tak naprawdę o nim.

  1. Styczeń 1998 — DEC przejęty przez Compaqa. Niegdysiejszy gigant, druga firma komputerowa świata, przestaje istnieć jako samodzielny byt.
  2. 2001 — wyrok na Alphę. Compaq ogłasza porzucenie rozwoju własnej, znakomitej architektury Alpha na rzecz intelowskiego Itanium. VMS traci swój naturalny, najlepszy sprzęt.
  3. 2002 — HP kupuje Compaqa. OpenVMS trafia pod skrzydła firmy o zupełnie innych priorytetach, w której inwestycje w system zaczynają wysychać.
  4. Ślepy zaułek Itanium. HP przenosi OpenVMS na Itanium — ale sam Itanium okazuje się komercyjną klapą, złośliwie przezywaną „Itanic”. System zostaje przywiązany do tonącej platformy.
  5. 2013 — HP zwija mapę drogową. Ogłoszenie końca rozwoju nowych wersji, brak planów portu na nowoczesne procesory, harmonogram wygaszania wsparcia. Dla wielu klientów to był wyrok śmierci. Wsparcie dla VAX-a i Alphy gasło (Alpha — do 2018), a przyszłości po prostu nie zaproponowano.

Około roku 2013 obraz był jednoznaczny: legendarny, niezniszczalny system po prostu się kończył — nie dlatego, że był zły, lecz dlatego, że żaden z kolejnych właścicieli nie miał w nim interesu. To jedno z najczystszych studiów przypadku tego, jak doskonała technologia przegrywa z logiką korporacyjnego portfela.

13. Zmartwychwstanie (2014 →)

I tu zaczyna się trzeci akt, którego prawie nikt się nie spodziewał.

W 2014 roku powstała firma VMS Software Inc. (VSI), która przejęła od HP całość biznesu rozwoju i wsparcia OpenVMS. Cel był podwójny: utrzymać przy życiu system dla klientów, którzy nigdy nie zmigrowali (banki, giełdy, fabryki, szpitale, infrastruktura krytyczna, instytucje rządowe) — i wyrwać go z tonącego Itanium, przenosząc na najpopularniejszą architekturę świata, x86-64. To czwarta wielka przeprowadzka systemu w jego historii:

1977 ── VAX ──► lata 90. ── Alpha ──► 2000s ── Itanium ──► 2020s ── x86-64

Port na x86-64 wymagał kilku sprytnych decyzji inżynierskich, z których jedna jest pięknym domknięciem wątku z rozdziału 4. Procesor x86-64 udostępnia cztery pierścienie ochrony, ale w praktyce użyteczne są tylko dwa — a VMS od zawsze opierał się na czterech trybach dostępu. Rozwiązanie? Brakujące poziomy zasymulowano programowo. To samo, co kiedyś robił PALcode na Alphie, teraz robi warstwa programowa na x86-64. Przy okazji zamieniono firmowy backend kompilatora (GEM) na otwarty LLVM i zmieniono proces startu tak, by system bootował z dysku w pamięci.

Kamienie milowe odrodzenia:

$ SHOW SYSTEM/NODE
OpenVMS V9.2-3  on node CLOUD01   21-JUN-2026 11:42:18.07  Uptime  412 03:18:55

  Pid    Process Name    State  Pri      I/O       CPU
00000041 SWAPPER         HIB     16        0   0 00:00:09.11
0000010C SYSTEM          LEF      9     4128   0 00:02:41.55
00000180 ANDERSON        CUR      4     1203   0 00:00:12.33
$

VSI uruchomiło też program Community License, dzięki któremu hobbyści i entuzjaści mogą legalnie postawić OpenVMS x86-64 we własnej maszynie wirtualnej. Po dekadach bycia systemem „tylko dla wielkich korporacji”, VMS w końcu trafił pod strzechy.

💡 Ciekawostka — pełne domknięcie koła. System z 1977 roku, zaprojektowany pod konkretny, fizyczny minikomputer wielkości lodówki, dziś żyje przede wszystkim jako maszyna wirtualna w chmurze — na architekturze x86-64, którą do świata pomógł wprowadzić nie kto inny jak Dave Cutler, już po stronie Microsoftu. Człowiek, który zbudował VMS-a, a potem (wedle złośliwych) „zabrał go” do Windowsa, nieświadomie przygotował grunt pod jego zmartwychwstanie.

14. Epilog

VMS to system, który wyprzedził epokę (wersjonowanie plików, klastry, blokada rekordowa, ACL), odcisnął się na świecie nie wprost (jako duch w każdym Windowsie), został zmuszony przez POSIX do założenia uniksowego kostiumu, trzy razy przeprowadzał się między architekturami procesorów, został pogrzebany przez korporacyjne fuzje — i wstał z grobu na x86-64, by działać tam, gdzie zaczynała się ta historia, tyle że teraz w chmurze.

Jego losy są przestrogą i pociechą zarazem. Przestrogą — bo pokazują, że doskonała technologia nie wygrywa sama z siebie; przegrywa z decyzjami zarządów, kaprysami rynku i strategicznymi błędami właścicieli. Pociechą — bo dowodzą, że dobrze zaprojektowana rzecz potrafi przeżyć własną śmierć, jeśli znajdzie się grupa ludzi gotowych ją podnieść.

„Systemy operacyjne umierają. VMS po prostu przeszedł na inny procesor.”

15. Ciekawostki zebrane

16. Oś czasu

Rok Wydarzenie
1975 DEC rozpoczyna projekt 32-bitowego rozszerzenia PDP-11 (VAX)
1977 Premiera VAX-11/780; ogłoszenie VAX/VMS (25 października)
1978 VAX/VMS V1.0
1982 Jednowęzłowy menedżer blokad (VMS V3.0)
1983 Ogłoszenie VAXcluster (maj)
1984 Klastry i rozproszony menedżer blokad w VMS V4.0
1986 Cliff Stoll wykrywa włamanie (Kukułcze jajo); LAVc po Ethernecie
1988 SMP w VMS V5.2; Dave Cutler odchodzi z DEC do Microsoftu
1988 Norma POSIX IEEE Std 1003.1-1988
1989 Robak WANK atakuje VMS-y w NASA/DOE (16 października); wydanie The Cuckoo's Egg
1991–92 VAX/VMS → OpenVMS (zgodność z POSIX); port na Alpha
1993 Premiera Windows NT (intelektualne dziecko VMS-a)
1994 OpenVMS V6.1 — równoważność funkcjonalna VAX/Alpha
1998 DEC przejęty przez Compaqa
2001 Compaq porzuca Alphę; ogłoszenie portu na Itanium
2002 HP przejmuje Compaqa
2003 Pierwsze uruchomienie OpenVMS na Itanium (31 stycznia)
2005 OpenVMS V8.2 — pierwsze produkcyjne wydanie na Itanium
2010 OpenVMS V8.4 — klastrowanie po TCP/IP
2013 HP ogłasza koniec mapy drogowej OpenVMS
2014 Powstaje VSI i przejmuje rozwój OpenVMS
2019 Pierwsze uruchomienie OpenVMS na x86-64 (14 maja)
2022 OpenVMS V9.2 — produkcyjnie na x86-64
2024 OpenVMS V9.2-3 — najnowsze wydanie (20 listopada)
2025 GNV V3.0-2E; OpenVMS żyje w chmurze i wirtualizacji

17. Źródła i dalsze lektury

Historia i architektura systemu

Czas hakerów

POSIX

Cutler, Windows NT i ugoda z DEC

Stan obecny (VSI, x86-64)

Uwaga: część dat „okołostandardowych” (POSIX, FIPS) oraz przejściowych (zmiana nazwy na OpenVMS) podawana jest w źródłach w przedziale 1988–1992, ponieważ procesy te rozciągały się na kilka lat. Kwoty ugody DEC–Microsoft różnią się między źródłami (ok. 100–180 mln USD).

Revision #2
Created 21 June 2026 18:25:34 by Tomasz Konieczny
Updated 21 June 2026 18:38:15 by Tomasz Konieczny