Powiada się, że oczy kierowcy, który nieco za szybko wszedł w zakręt, zdają się występować z oczodołów wypatrując, kiedy zakręt stanie się ponownie prostą. Podobnego, zdaje się, uczucia doświadczył każdy, kto uruchamiał na komputerze jakiś większy program, bądź pracę takiego programu nadzorował, gdy program taki według wszelkich przesłanek dawno powinien się zakończyć, a tu działa on sobie i działa...

Nie jest to powodem do wielkich obaw, gdy wszystko odbywa się jeszcze na niby, w trakcie prób i testów. Problem zaczyna się, gdy komputer liczy i liczy, a nieuchronnie zbliża się godzina, kiedy to ma on zająć się zupełnie czymś innym, do czego potrzebne jednak będą wyniki z programu, który jakoś nie może się zakończyć.

A bywało tak już nawet w zamierzchłej przeszłości, czego sam doświadczyłem ileś razy, że kilkugodzinny bufor między końcem nocnego przetwarzania wsadowego, a początkiem porannej sesji zdalnego dostępu wypełniało powtórzenie całego przebiegu wsadowego, w którym coś poszło nie tak. Wtedy robiło się nagle ciasno, bo punktualność uruchamiania dostępu online była oczkiem w głowie szefów.

Nie najgorzej jeszcze bywa z programami, które dają jakieś sygnały pośrednie o tym, że być może czynią w swym działaniu postępy. Zupełnie nie rozumiem jednak i nigdy nie uzyskałem zadowalającej odpowiedzi na pytanie, jak poznać, że nie krąży w martwej pętli program, który na początku przeczytał ileś tam liczb, a obliczenia na nich ma zakończyć wydrukowaniem jednostronicowej tabeli, po np. 15 godzinach pełnego obciążania procesora.

Do refleksji tych skłoniła mnie prośba pewnego studenta, który pisząc pracę o giełdowych systemach informatycznych, dotarł do mojego felietonu sprzed pięciu lat, o którym sam już dawno zapomniałem. Prosił mnie ów student o bliższe dane o fali przypadków spektakularnych awarii, jaka przetoczyła się przez europejskie giełdy w roku 2000. Materiały te szczęśliwie odnalazłem i mogłem wysłać, ale i sam z zainteresowaniem ponownie przeczytałem.

Co zastanawiające - wszystkie niemal te przypadki skończyły się odwołaniem sesji giełdowych z powodu niezakończenia się na czas nocnych programów wsadowych. Operatorzy komputerów mieli świadomość tego, co się dzieje, ale nie wiedzieli, czy mogą przerwać bieg programu bez poważnych konsekwencji, bo takiego obrotu spraw nie przewidywała żadna procedura.

Nauka jednak nie poszła w las i podobnego błędu uniknęli niedawno Japończycy. Ich przypadek był o tyle inny, że zdarzył się pod koniec sesji, a nie jeszcze przed jej rozpoczęciem. Z powodu, o którym dziś głośno (skandal z firmą internetową Livedoor), a który był wtedy bardziej jeszcze plotką niż stwierdzonym faktem, rozpoczął się paniczny obrót akcjami. Wynikiem był gwałtowny wzrost liczby transakcji do przetworzenia. System tokijskiej giełdy potrafi przetworzyć dziennie do 4,5 mln transakcji (lub 5, jak chcą inni). Gdy, w feralnym dniu, liczba ta przekroczyła 4 mln, do końca sesji zostawało 20 min. Nie czekano tam jednak na rozwój wypadków, jak w pamiętnym filmie "Grek Zorba" ("... szefie!, co za wspaniała katastrofa!..."), lecz twardo zdecydowano o natychmiastowym i przedterminowym zakończeniu sesji.

Za niemal pewnik można przyjąć, że decyzji tej nie byli władni podjąć sami operatorzy systemu komputerowego, lecz ktoś stojący w hierarchii znacznie wyżej, ze sfer bliskich władzom giełdy, a więc bardziej z kół biznesu, niż informatyki.

Nie byłoby to możliwe bez pełnego zaufania i zrozumienia między tamtejszymi przedstawicielami obu tych stron. Niestety - stan taki w dzisiejszym świecie to ciągle wyjątek, a nie reguła...