Dawne systemy informatyczne na PKP lata 90

TechEkspert napisał:

Zobaczymy, może temat przyciągnie użytkowników elektrody lub google i znajdą się osoby, które wiedzą jak to działało. Moim zdaniem było to bardzo nowoczesne rozwiązanie jak na lata, w których zostało uruchomione. Ciekawe czy pasażer naciskający ciągle przycisk "enter" mógł DDoSować mainframe, który to obsługiwał lub wykonać coś w rodzaju "sql injecion"

Zapytamy jeszcze bota @ElektrodaBot czy posiadasz informacje o systemie komputerowym informacji pasażerskiej stosowanym na niektórych dworcach przez PKP w Polsce? Były to terminale w grupach po cztery z monochromatycznymi wyświetlaczami, które na dworcach pozwalały na wyszukiwanie połączeń w rozkładach jazdy. Urządzenia te działały w latach 80/90 i ze względu na obecny stan techniki raczej nie były samodzielnymi komputerami a bardziej terminalami systemu typu mainframe. Jaki system mainframe mógł być wykorzystany? Czy terminale nazwijmy to "sprzętowe putty" to mogły być Mera 9150 lub IBM 3270 zamontowane na stojakach maskujących podłączenie zasilania i komunikacji? Jak komunikowały się takie terminale z komputerem?

Moim zdaniem najbardziej prawdopodobny scenariusz jest taki, że to nie były samodzielne komputery PC, tylko publiczne terminale znakowe pracujące z centralnym systemem rozkładowym PKP, przy czym hipoteza „IBM 3270 / klasa 3270” jest technicznie dużo bardziej przekonująca niż Mera 9150.

Krótka odpowiedź

Najkrócej:

- tak – architektura terminal + system centralny jest tu bardzo prawdopodobna,
- nie stawiałbym na Mera 9150 jako najbardziej trafny typ urządzenia,
- bardziej prawdopodobne są:
- terminale klasy IBM 3270 albo
- polskie / RWPG kompatybilne odpowiedniki 3270,
- system centralny mógł pracować na:
- IBM System/370, 43xx, ES/9000,
- albo maszynie zgodnej z IBM/360/370 z rodziny JS EMC / RIAD / R-32 / R-4x,
- znacznie mniej przekonująco wygląda tu klasyczna Odra 1300 jako host takiej publicznej usługi terminalowej.

Jeżeli pytanie brzmi: „co było najbardziej typowe technologicznie dla takiego zastosowania?”, to odpowiedź brzmi:
terminal blokowy + kontroler + centralny host transakcyjny.

---

Co w przykładowych odpowiedziach jest trafne, a co wymaga korekty

Co jest trafne

Najmocniejsze punkty z podanych odpowiedzi:

- terminale publiczne z lat 80/90 faktycznie mogły być „głupimi” terminalami,
- IBM 3270 to bardzo ważny trop,
- komunikacja raczej nie była „jak dzisiejszy SSH/Telnet znak po znaku”, tylko mogła działać blokowo,
- po stronie centrum mógł siedzieć system mainframe / host transakcyjny,
- pytanie o „DDoS Enterem” jest zabawne, ale technicznie sensowne.

Co wymaga ostrożności

1. Mera 9150
To moim zdaniem słabszy kandydat. Mera 9150 była kojarzona bardziej z wielostanowiskowym systemem rejestracji/przygotowania danych, a nie z typowym publicznym terminalem dworcowym. Sam monochromatyczny ekran i polskie pochodzenie jeszcze nie czynią jej dobrym typem dla kiosku pasażerskiego.

2. „Na pewno IBM 3270”
Tego też nie da się uczciwie powiedzieć bez dokumentacji lub zdjęcia wnętrza. Bardziej poprawnie:
- mogło to być urządzenie zgodne funkcjonalnie z 3270,
- niekoniecznie oryginalny terminal IBM.

3. Odra jako oczywisty host
PKP rzeczywiście używało różnych dużych systemów, ale do takiego rozwiązania publicznego bardziej pasuje platforma mainframe’owa z rozwiniętą obsługą terminali transakcyjnych niż klasyczne skojarzenie „PKP = Odra”.

---

Najbardziej prawdopodobna architektura

1. Co stało na dworcu

Opis użytkowników bardzo dobrze pasuje do:

- 4 stanowisk osadzonych w jednej wspólnej metalowej zabudowie,
- każdego stanowiska z:
- monitorem CRT mono,
- klawiaturą wandaloodporną,
- prostą elektroniką terminalową,
- wspólnym prowadzeniem:
- zasilania,
- okablowania transmisyjnego,
- ewentualnie jednego lokalnego kontrolera.

To mogło być zrealizowane na dwa sposoby:

Wariant A – prawdziwe terminale ekranowe
Każde stanowisko było osobnym terminalem znakowym, np. klasy 3270 lub podobnej.

Wariant B – terminale „kioskowe” z logiką dedykowaną
W środku mogły siedzieć nie tyle katalogowe terminale biurowe, co specjalne moduły ekranowe / terminalowe zrobione do konkretnego zastosowania, ale nadal pracujące jako końcówki hosta.

W praktyce dla użytkownika oba warianty wyglądały podobnie.

---

2. Dlaczego 3270 pasuje lepiej niż „sprzętowe putty”

Porównanie do PuTTY jest intuicyjnie zrozumiałe, ale technicznie nie do końca trafne.

Terminale klasy IBM 3270 pracowały zwykle w trybie blokowym:

- użytkownik wpisywał dane w pola ekranu,
- terminal trzymał to lokalnie w buforze,
- dopiero po naciśnięciu klawisza typu Enter / PF / PA wysyłany był cały blok danych do hosta.

To bardzo dobrze pasuje do kiosku z formularzem:

- OD
- DO
- ewentualnie data / godzina / typ połączenia

Taki tryb pracy ma kilka zalet:

- mniejsze obciążenie łącza niż transmisja znak-po-znaku,
- większa odporność na opóźnienia,
- łatwiejsza kontrola formatki po stronie systemu centralnego,
- przewidywalne zachowanie w publicznym terminalu.

---

3. Jak mogła wyglądać komunikacja

Najbardziej prawdopodobny łańcuch był taki:

W obrębie dworca:
- terminale → lokalny kontroler terminali
przez przewody dedykowane dla danej architektury, np. współosiowe lub inne łącza terminalowe.

Z dworca do centrum:
- kontroler → modem / urządzenie transmisji danych,
- dalej:
- łącze dzierżawione,
- kolejowa sieć teletechniczna,
- linia synchroniczna do centrum obliczeniowego.

W centrum:
- front-end komunikacyjny / kontroler teleprzetwarzania,
- host mainframe,
- aplikacja rozkładowa.

Czyli raczej nie:
- „każdy terminal miał własny modem telefoniczny”,
- ani „szedł zwykły RS-232 prosto do odległego komputera centralnego”.

RS-232 mogło wystąpić lokalnie w jakimś podukładzie, ale jako architektura systemu ogólnopolskiego to za mało przekonujące.

---

Jaki host mógł to obsługiwać

Tu trzeba oddzielić „co było możliwe” od „co najbardziej prawdopodobne”.

Najbardziej prawdopodobne klasy systemów

1. Host zgodny z architekturą IBM /370
To byłby bardzo naturalny wybór dla systemu transakcyjnego z wieloma terminalami.

Mogło to być:
- oryginalne IBM System/370,
- późniejsze IBM 43xx,
- w latach 90. nawet nowsza rodzina IBM.

2. Maszyna zgodna z IBM w ramach JS EMC / RIAD
W realiach PRL i okresu przejściowego to również bardzo realne.

Jeżeli aplikacja i infrastruktura terminalowa były wzorowane na IBM-owskim modelu pracy, to host nie musiał być fizycznie IBM-em, by zachowywać się „jak IBM”.

3. Polski system centralny z warstwą terminalową
Teoretycznie możliwe, ale mniej oczywiste bez dokumentacji.

---

A co z Odrą?

Odra była na PKP obecna, ale:

- nie każda duża maszyna nadawała się równie dobrze do publicznej, masowej usługi terminalowej,
- sam fakt używania Odr w innych działach PKP nie oznacza, że właśnie one obsługiwały kioski pasażerskie.

Moja ocena:
- nie można tego wykluczyć,
- ale nie traktowałbym Odry jako głównego faworyta dla akurat tej konkretnej usługi.

---

Czy to mogła być Mera 9150?

Krótko: raczej nie jako główny typ kandydata.

Powody:

- Mera 9150 była kojarzona z systemem rejestracji danych,
- to nie jest najbardziej naturalny rodowód dla publicznego kiosku wyszukującego połączenia,
- opis „terminal w ciężkiej stalowej zabudowie na dworcu” bardziej pasuje do:
- terminala ekranowego klasy systemowej,
- albo specjalizowanej końcówki kioskowej,
- niż do rozwiązania typowo „data entry”.

Jeżeli już szukać po linii MERA, to prędzej wśród terminali zgodnych z rodziną 3270 / 7900, a nie wprost w Mera 9150.

---

Czy to mogły być IBM 3270?

Tu odpowiedź jest bardziej pozytywna, ale z zastrzeżeniem:

- mogły być,
- ale równie dobrze mogły to być kompatybilne odpowiedniki.

W praktyce publiczny kiosk PKP mógł używać:

- oryginalnej elektroniki IBM,
- polskiego klona / kompatybilnego terminala,
- terminala dedykowanego emulującego zachowanie klasy 3270.

Czyli na forum najuczciwiej byłoby napisać:

> Jeśli patrzeć po sposobie działania i epoce, najbardziej pasuje architektura zbliżona do IBM 3270, ale bez zdjęć wnętrza lub dokumentacji nie ma podstaw, by wskazać dokładny model.

---

Jak działało wyszukiwanie połączeń

To najpewniej nie był „wolny tekst” w dzisiejszym sensie, tylko aplikacja formularzowa.

Przykładowy przebieg:

1. Host wyświetla ekran z polami:
- stacja początkowa,
- stacja końcowa,
- ewentualnie data/godzina.
2. Użytkownik wypełnia pola.
3. Naciska Enter.
4. Terminal wysyła blok danych.
5. Aplikacja centralna:
- sprawdza poprawność nazw / kodów stacji,
- przeszukuje bazę rozkładów,
- odsyła wynik jako nowy ekran tekstowy.

To dobrze tłumaczy, dlaczego nawet przy małej przepływności łączy system mógł działać akceptowalnie.

---

Czy dało się to „DDoS-ować Enterem”

W sensie współczesnym: praktycznie nie.

Dlaczego

1. Tryb blokowy
Nie każde naciśnięcie klawisza generowało transmisję.

2. Blokada klawiatury podczas oczekiwania
W wielu terminalach po wysłaniu żądania klawiatura była blokowana do czasu odpowiedzi hosta. Czyli „spamowanie Enterem” często kończyło się lokalnie.

3. Ograniczona wydajność interfejsu człowiek–maszyna
Nawet bardzo zdeterminowany pasażer generował śmiesznie mały ruch względem dzisiejszych pojęć.

4. Kontrola przez host/kontroler
Kontroler terminali i aplikacja centralna mogły:
- odrzucać puste żądania,
- wymuszać kompletność pól,
- narzucać timeouty.

Natomiast uczciwie trzeba dodać:
- lokalne „zapchanie” kolejki było teoretycznie możliwe,
- szczególnie jeśli 4 osoby równocześnie generowały dużo bezsensownych zapytań,
- ale to raczej oznaczałoby spowolnienie kiosku, nie „obalenie mainframe’u”.

---

Czy można było zrobić „SQL injection”

Bardzo mało prawdopodobne.

Powody techniczne

1. To prawdopodobnie nie był system SQL-owy w nowoczesnym sensie
Często były używane:
- pliki indeksowane,
- bazy hierarchiczne,
- aplikacje transakcyjne pisane na sztywno.

2. Pola na ekranie były zwykle silnie zdefiniowane
- długość pola,
- pozycja na ekranie,
- dozwolony typ danych.

3. Mały zestaw znaków i funkcji
Klawiatura publiczna zwykle nie dawała pełnej swobody wpisywania „dziwnych” sekwencji.

4. Aplikacja była proceduralna
Program nie składał dynamicznie tekstowego zapytania SQL z wejścia użytkownika tak, jak robiły to później źle napisane aplikacje webowe.

Czyli:
- „SQL injection” — praktycznie nie,
- ale różne błędy walidacji danych wejściowych były oczywiście możliwe.

---

Co moim zdaniem było najbardziej prawdopodobne technicznie

Wersja robocza, najbardziej spójna

Terminal publiczny PKP na dworcu
↓
lokalny kontroler wielostanowiskowy
↓
łącze synchroniczne przez sieć kolejową / dzierżawioną
↓
host transakcyjny klasy IBM/370 lub kompatybilny
↓
dedykowana aplikacja rozkładu jazdy

Sprzęt terminalowy:
- niekoniecznie Mera 9150,
- raczej terminal lub emulacja klasy 3270,
- możliwe polskie wykonanie i specjalna obudowa kioskowa.

Oprogramowanie:
- dedykowana aplikacja formularzowa,
- prawdopodobnie bez „swobodnej” pracy użytkownika poza przewidzianym scenariuszem.

---

Co mogłoby potwierdzić identyfikację

Najbardziej pomogłyby:

1. Zdjęcie ekranu lub wspomnienie układu
Jeśli ekran miał:
- ramki,
- pola wejściowe,
- numerowane funkcje,
- bardzo „systemowy” układ tekstu,

to wzmacnia hipotezę 3270 / systemu blokowego.

2. Zdjęcie klawiatury
Jeśli były nietypowe klawisze funkcyjne albo układ zbliżony do terminalowego, to dużo mówi.

3. Wspomnienie szybkości działania
- Jeśli po naciśnięciu Enter była wyraźna chwila oczekiwania i potem „przeskakiwał cały ekran”, to bardzo pasuje do pracy blokowej.
- Jeśli znaki pojawiały się od razu lokalnie i dopiero wynik przychodził z hosta, to również pasuje.

4. Archiwa PKP / zdjęcia dworców
To może być jedyna droga do identyfikacji konkretnego modelu.

---

Wniosek końcowy

Moja techniczna ocena jest taka:

1. To prawie na pewno były terminale systemu centralnego, a nie autonomiczne pecety.
2. Mera 9150 nie jest najlepszym typem, choć nazwa pojawia się intuicyjnie z racji epoki i polskiego pochodzenia.
3. Najbardziej prawdopodobna jest architektura klasy IBM 3270 albo kompatybilna.
4. System centralny mógł działać na:
- IBM mainframe,
- albo kompatybilnym hoście z rodziny JS EMC / RIAD / R-32,
- mniej przekonująco: klasyczna Odra jako bezpośredni host tej konkretnej usługi.
5. Komunikacja najpewniej była:
- blokowa,
- przez kontroler terminali,
- z wykorzystaniem łączy synchronicznych / infrastruktury teletransmisyjnej PKP.
6. „DDoS Enterem” i „SQL injection” w dzisiejszym rozumieniu raczej nie miały tu zastosowania.

---

Gdybym miał napisać jedną, forumową odpowiedź w skrócie

> Najbardziej prawdopodobne, że były to publiczne terminale znakowe pracujące z centralnym hostem, raczej w architekturze zbliżonej do IBM 3270 niż Mera 9150. Na dworcu mógł stać kontroler obsługujący kilka stanowisk, a dalej ruch szedł łączem do centrum obliczeniowego PKP. To nie musiał być oryginalny IBM — równie dobrze polski lub „obozowy” kompatybilny odpowiednik. Enterem raczej nie dało się tego skutecznie „zDDOS-ować”, bo terminale blokowe wysyłały całe formularze, a po żądaniu często blokowały klawiaturę do czasu odpowiedzi hosta.

Jeżeli chcesz, mogę w następnym kroku przygotować jeszcze:
1. porównanie Mera 9150 vs IBM 3270 vs typowy terminal kioskowy w tabeli,
albo
2. rekonstrukcję najbardziej prawdopodobnego schematu połączeń takiego kiosku PKP.