Cyfrowa Twierdza

Rozdział 34

Susan siedziała sama w Węźle nr 3. i czekała na wiadomość. Hale postanowił wyjść i zaczerpnąć świeżego powietrza – była mu za to wdzięczna. Samotność w Kojcu nie dała jej jednak niezbędnego azylu. Wciąż myślała o związku między Tankadem i Hale’em.

– Kto ma pilnować tych, co pilnują? – powiedziała do siebie. Quis custodiet ipsos custodes. Te słowa uporczywie wracały do niej. Zmusiła się, by przestać je analizować.

Pomyślała o Davidzie. Miała nadzieję, że nic mu się nie stało. Wciąż nie mogła pogodzić się z myślą, że jest w Hiszpanii. Im prędzej znajdą klucze i skończą tę historię, tym lepiej.

Susan nie wiedziała już, jak długo siedzi i czeka na wiadomość. Dwie godziny? Trzy? Spojrzała na pustą główną salę Krypto i westchnęła. Chciała, żeby wreszcie rozległ się sygnał terminalu, ale panowała kompletna cisza. Słońce już zaszło, było przecież późne lato. Automatycznie włączyło się oświetlenie. Susan czuła, że czas nagli.

Spojrzała na terminal.

– No, kończ już – mruknęła. – Miałeś dość czasu. – Chwyciła mysz i kliknęła, żeby otworzyć okienko wyświetlające status TRACERA. – Jak długo to już trwa?

Okienko natychmiast się otworzyło. Cyfrowy zegar wskazywał czas, jaki minął od wysłania TRACERA. Susan oczekiwała, że zobaczy, ile upłynęło godzin i minut. Zamiast tego przeczytała coś zupełnie innego i poczuła, że serce podchodzi jej do gardła.

WYKONANIE PROGRAMU TRACER PRZERWANE

– Co takiego?! – wykrztusiła głośno. – Dlaczego?

W panice gwałtownie przeglądała dane, poszukując instrukcji, która mogłaby spowodować przerwanie wykonania programu. Na próżno. Wyglądało na to, że TRACER przerwał sam z siebie. Wiedziała, że to może znaczyć tylko jedno – w programie pojawiła się jakaś pluskwa.

Susan uważała „pluskwy” za najbardziej denerwującą część programowania. Komputery wykonują ściśle podane instrukcje, dlatego nawet drobne błędy często powodują katastrofę. Prosty błąd syntaktyczny – na przykład użycie przecinka zamiast kropki – może rzucić cały system na kolana. Susan zawsze myślała, że slangowy termin „pluskwa” ma zabawny rodowód.

Słowo to pochodziło z czasów budowy pierwszego komputera – MARK l – elektromechanicznego układu wielkości całego pokoju, skonstruowanego w 1944 roku na Uniwersytecie Harvarda. Pewnego dnia komputer przestał działać i bardzo długo nikt nie był w stanie znaleźć przyczyny. Po wielu godzinach pewien laborant dostrzegł problem. Jakaś ćma usiadła na płytce z obwodami elektrycznymi i spowodowała krótkie spięcie. Od tej pory na błędy komputerowe mówiono „pluskwy”.

– Nie mam czasu na takie głupstwa – zaklęła Susan.

Szukanie błędu w programie niekiedy trwa wiele dni. Program może mieć kilka tysięcy linii, a trzeba znaleźć jeden drobny błąd. To niczym przeszukiwanie tomu encyklopedii w celu znalezienia jednej literówki.

Susan wiedziała, że nie ma wyboru – może tylko spróbować ponownie wysłać program TRACER. Niestety było prawie pewne, że ten sam błąd znowu spowoduje przerwanie operacji. Szukanie błędu wymagało czasu, a ani ona, ani komandor po prostu go nie mieli.

Gdy wpatrywała się w listę instrukcji programu, zdała sobie sprawę, że coś tu nie gra. Miesiąc wcześniej skorzystała z TRACERA i nie miała żadnych kłopotów. Dlaczego właśnie teraz miałby pojawić się jakiś błąd?

W tym momencie przypomniała sobie komentarz Strathmore’a: Chciałem sam wysłać kopię twojego TRACERA, ale napisałaś to cholerstwo w jednym z tych nowych, hybrydowych języków i nie udało mi się go uruchomić. Wciąż dostawałem jakieś bzdury.

Susan zastanowiła się nad tym słowami. Dostawałem jakieś bzdury…

Pochyliła głowę. Czy to możliwe? Strathmore otrzymał jakąś odpowiedź…

Jeśli komandor dostał jakąś odpowiedź, to najwyraźniej TRACER działał. Susan przyjęła, że wynik był bezsensowny, ponieważ Strathmore źle podał dane – ale mimo to program zadziałał.

Były oczywiście jeszcze inne możliwe wyjaśnienia, dlaczego operacja została przerwana. Programy padają nie tylko z powodu błędów programistów. Czasami przyczyną są czynniki zewnętrzne: zmiany napięcia zasilania, drobiny kurzu na płytach, błędne połączenia. Hardware w Węźle nr 3 był utrzymywany w tak nienagannym stanie, że Susan początkowo nawet nie pomyślała o tej możliwości.

Wstała i szybko podeszła do dużej półki zastawionej poradnikami technicznymi. Wzięła do ręki oprawiony w spirale tom oznaczony SYS-OP i zaczęła przerzucać strony. Znalazła to, czego szukała, i wróciła do terminalu z poradnikiem. Szybko wystukała kilka poleceń. Czekała przez chwilę, aż komputer przejrzy listę wszystkich instrukcji wykonanych w ciągu ostatnich trzech godzin. Miała nadzieję, że znajdzie jakąś zewnętrzną przyczynę – na przykład polecenie przerwania wykonania programu z powodu fluktuacji napięcia zasilającego.

Po chwili terminal pisnął. Susan poczuła, że jej tętno przyśpiesza. Wstrzymując oddech, wpatrywała się w ekran:

BŁĄD NR 22

Poczuła iskierkę nadziei. To była dobra wiadomość. Skoro komputer znalazł błąd, to TRACER był zapewne w porządku. Najprawdopodobniej wystąpiła jakaś zewnętrzna anomalia, której powtórzenie się było mało prawdopodobne.

BŁĄD NR 22. Susan próbowała sobie przypomnieć, co to znaczy. Awarie sprzętowe zdarzały się tak rzadko, że nie pamiętała wszystkich oznaczeń.

Szybko przerzuciła kartki poradnika SYS-OP w poszukiwaniu listy błędów.

19. WADLIWA PARTYCJA DYSKU

20. FLUKTUACJA NAPIĘCIA

21. AWARIA ZASILANIA

Gdy doszła do numeru 22, aż znieruchomiała. Raz jeszcze pojrzała na ekran, żeby się upewnić.

BŁĄD NR 22

Zmarszczyła brwi i wróciła do poradnika SYS-OP. To zupełnie bez sensu, pomyślała. Wyjaśnienie było bardzo krótkie:

22. WYKONANIE PRZERWANE NA POLECENIE OPERATORA