Przepisywanie asemblera IBM + COBOL w C ++

Pracuję jako agent / kierownik wypożyczalni w firmie wynajmującej samochody, która działa w systemie wynajmu napisanym w 1972 roku. Zdecydowałem, że może nadszedł czas na aktualizację. Dla odrobiny tła, oto krótki przykład szaleństwa, z którym mamy do czynienia codziennie w tym programie:

Agent wypożyczający musi pamiętać, że drukowanie na jednym ekranie używa „MXC” w polu ACT (wszystko opiera się na krótkich kodach), co kłopotliwie oznacza „MaXimum wyświetlanie na umowie”, podczas gdy na innym wymaga PR (dla PRint) w w polu AKCJA, ale kilka ekranów używa litery Y w polu PT (dla PrinT), jeszcze inny ekran używa litery Y w polu PRT (dla PRinT), jeszcze inny ekran wymaga naciśnięcia przez użytkownika klawisza Enter (ale nie klawisza obok litery, ponieważ jest to nowy znak linii, musi to być znak na klawiaturze numerycznej), a następnie F8, inny, ale powiązany ekran wymaga po prostu F8, niektóre ekrany mają pole oznaczone PRT, które powinno być dla PRinT, ale pole to w rzeczywistości nic nie robi, a drukowanie odbywa się automatycznie po przejściu kilku monitów, a jeszcze więcej ekranów ma pole oznaczone DRUKUJ T / N,która niesamowicie domyślnie ma wartość Y dla operacji, w których inna lokalizacja już dostarcza dokumenty, oraz N dla operacji, w których inny dealer będzie potrzebował dokumentów.

Zdecydowałem, że mogę wykonać lepszą robotę, więc postanowiłem skontaktować się z osobą w firmie, która podejmie decyzję o aktualizacji. W końcu docieram do wiceprezesa działu IT odpowiedzialnego za ten program. Wyciągam od niego trochę informacji i dowiaduję się, że moja wypożyczalnia samochodów ma program wypożyczania napisany w asemblerze komputerów mainframe IBM z domieszką odrobiny COBOL. Mówi, że obecnie nie ma żadnych otwartych pozycji, ale powinienem mimo to wyślij mu moje e-mailem (na wypadek, gdyby coś się otworzyło).

To prowadzi mnie do moich pytań.

Pierwszy jest techniczny. Z myślą o poprawie łatwości konserwacji w przyszłości, moim pomysłem jest przepisanie go w języku wyższego poziomu niż w języku asemblera. Moje doświadczenie obejmuje C ++, więc jest to dla mnie oczywisty wybór. Firma pilnie potrzebuje łatwiejszego sposobu aktualizacji programu, ponieważ niedawno przeczytałem artykuł, w którym cytowany mężczyzna mówi, że zespół ciężko pracował i z dumą ogłaszają, że program obsługuje teraz 5 - cyfrowe kody lokalizacji (zamiast 4) i 8-cyfrowe numery samochodów (zamiast 7). Moja filozofia aktualizacji, nawet w tak trudnych sytuacjach, jest zgodna z zasadą Joela: http://www.joelonsoftware.com/articles/fog0000000069.html w skrócie, ponowne zapisywanie powinno być przyrostowe, zamiast wyrzucać wszystko, co było wcześniej i zaczynać od nowa.

Czy istnieje prosty sposób na zintegrowanie zestawu IBM z C ++, a jeśli tak, to jak mam to zrobić? Nie jestem w pełni świadomy słowa kluczowego asm, ale nie wiem, czy najlepiej go użyć, czy zrobić coś innego. Czy taki plan jest niewłaściwy? Większość pracy w Linuksie wykonuję przy użyciu g ++ i GNU make, więc odpowiedzi na te pytania są mile widziane, ale zdecydowanie nie są wymagane (ponieważ nie mam pojęcia, jakiego rodzaju systemu budowania nie mają, ale podejrzewam, że prawie żadnego).

Drugie pytanie jest bardziej polityczne. Jak powinienem przekonać tę firmę, że muszą dokonać zmiany? Teoretyczne oszczędności kosztów są ogromne (na podstawie moich szacunków firma marnuje dodatkowy milion dolarów rocznie, tylko na zwiększone koszty szkolenia, aby nauczyć się, jak wchodzić w interakcje z programem), ale moje proponowane zmiany prawdopodobnie spowodowałyby wszystkie obecni programiści bez pracy, jeśli zostaną uchwaleni, więc istnieje duża strukturalna odporność na zmiany.

edycja: Powinienem wyjaśnić, dlaczego modyfikowanie tego, co już ma firma, wydaje mi się najlepszym rozwiązaniem. Nadal jestem otwarty na inne sugestie, ponieważ jest to jednak potwór programu. Nigdy wcześniej nie miałem pracy programistycznej, więc poprawcie mnie na podstawie jakiejkolwiek niepoprawnej analizy.

Po pierwsze, istnieje gotowe rozwiązanie.

Z moich rozmów z kilkoma menedżerami średniego szczebla na ten temat, jednym z głównych problemów związanych z przejściem na nowy system jest duża liczba lojalnych pracowników, którzy pracują w firmie od dziesięcioleci i do tej pory czują się dobrze z systemem . Jeśli mam możliwość modyfikowania tego, co mamy, mógłbym utrzymać obecny interfejs w rodzaju „trybu zgodności”. Użytkownicy muszą się już zalogować, aby korzystać z obecnego systemu, więc mógłbym dodać możliwość aktywowania ustawienia, gdy użytkownicy logują się po raz pierwszy (po wprowadzeniu tej zmiany), w przypadku gdy mają opcję użycia albo „klasyczny” interfejs lub „nowy” interfejs. Nie ma mowy, żebym znalazł gotowe rozwiązanie, które na to pozwala,

Moja firma jest również właścicielem oprogramowania, którego używamy; nie udzielamy licencji. Oznacza to, że kierownictwo, z którym obecnie rozmawiam, to te same osoby, które mogą faktycznie upoważnić mnie do wprowadzenia zmian. Dzięki rozwiązaniu innej firmy musiałbym uzyskać zgodę mojej firmy, oprócz zapewnienia wszelkich praw, które byłyby konieczne od firmy, która opracowała produkt, którego używamy, co stanowi dodatkową przeszkodę. Wymagałoby to również przekonania firmy, by zrezygnowała z „swojego” produktu i wybrała inny produkt, co wydaje się większą przeszkodą niż próba aktualizacji tego, co mamy, ale bardzo dobrze mogę się mylić w tej kwestii.

Wreszcie, patrząc w przyszłość, nie chcę tylko poprawić interfejsu użytkownika i naprawić kilka błędów. Po zaktualizowaniu tych „pilnych” problemów miałem nadzieję zaktualizować podstawowy sposób działania firmy związany z technologią. Po spędzeniu 1-2 lat na tego rodzaju sprawach, moim planem było wrócić do zarządzania i zaproponować bardziej dramatyczne zmiany. Istnieje wiele sposobów działania firmy, które można zasadniczo ulepszyć dzięki technologii, której po prostu obecnie nie używają. Na przykład każdy region działa w ten sam sposób. Największe lokalne lotnisko jest centralnym punktem dystrybucji samochodów. Są one wysyłane przede wszystkim według potrzeb. Jednak lotnisko jest wykorzystywane jako baza macierzysta dla wszystkich operacji. Wyślą dwie osoby w jednym samochodzie do mojej lokalizacji, aby odebrać od nas jeden samochód, którego nie potrzebujemy, potem wróć na lotnisko z samochodem, do którego przyjechali, plus to, co zabierają (jesteśmy 32 mile od lotniska). Następnie przybędą do miejsca oddalonego o 5 mil od nas dwoma samochodami, aby wysadzić jeden z nich, a następnie powrócić drugim samochodem na lotnisko. Robią to, nawet jeśli samochód, który odesłaliśmy, jest tym samym rodzajem samochodu, którego potrzebują w pobliżu. Jestem w firmie od około dwóch lat i wydaje mi się, że odbiegają od tego w najbardziej ekstremalnych przypadkach niedoborów samochodów (około trzy razy w historii). Zastąpiłbym 4 osoby pracujące w każdym regionie zautomatyzowanym systemem planowania, który określa, dokąd jadą samochody i staram się znaleźć ścieżkę, która wymaga najmniej czasu + mil + kierowców, aby dostarczyć wszystkie samochody tam, gdzie powinny być, jako przykład poprawek na wyższym poziomie Mam nadzieję, że kiedyś dodam.

Jednak zanim poczuję się swobodnie, proponując to wszystko, uważam, że pomocne byłoby uzyskanie pewności w firmie i bazie kodu, wykonując mniejsze zadania, takie jak aktualizacja interfejsu. Rozwiązania takie jak outsourcing lub w inny sposób wyeliminowałyby tę możliwość.

Ograniczając się do frontu technicznego ...

Proponuję rozpocząć od określenia środowiska, w którym działa aplikacja. „Komputer mainframe” może oznaczać kilka różnych rzeczy, biorąc pod uwagę wiek aplikacji, może to być CICS lub IMS . Możliwe jest również, że oryginalni autorzy napisali własne rozpoczęte zadanie.

W zależności od tego, gdzie aplikacja działa, prawdopodobnie będzie korzystać z interfejsów API dla tego środowiska, CICS używa teraz interfejsu znacznie różniącego się od swoich początkowych dni, nie mogę mówić o IMS. Jeśli aplikacja jest uruchomionym przez siebie zadaniem, to równie dobrze może mieć swój wewnętrzny interfejs API - spędzam około siedmiu lat wspierając taką bestię, napisaną w tej samej erze.

Biorąc pod uwagę wiek aplikacji, należy wziąć pod uwagę jeszcze to, że asembler, z którym chcesz zintegrować C ++, poprzedza istnienie środowiska językowego (LE). W związku z tym, chyba że Asembler został zaktualizowany, aby był zgodny z LE, będziesz mieć pewne trudności, ponieważ C i C ++ są zgodne z LE i będą wymagać od swoich wywołujących i osób odbierających również zgodności.

Inną kwestią do rozważenia, jeśli ta aplikacja działa na konającej platformie komputerowej, możesz próbować zintegrować się z aplikacją działającą na nieobsługiwanym sprzęcie i oprogramowaniu. Nie inaczej byłoby w przypadku próby integracji z aplikacją napisaną w 1989 roku, która działa na DOS 4.01 na oryginalnym sprzęcie.

Skaczesz z pistoletu. Z twojego opisu wygląda na to, że nie w pełni zrozumiałeś obecne środowisko techniczne (jaki dokładnie system operacyjny, gdzie i jak przechowywane są dane, czy istnieją interfejsy do innych systemów itp.). Ale jeszcze ważniejsze: poważny plan powinien rozważyć alternatywy dla częściowego lub całkowitego przepisania oprogramowania wewnętrznego, a mianowicie gotowe oprogramowanie, outsourcing przepisywania, oprogramowanie jako usługa itp.

Niezależnie od tego, w jaki sposób firma w końcu pójdzie, najpierw potrzebuje rzetelnej analizy tego, co oprogramowanie robi dzisiaj i jakie są wymagania dotyczące nowego rozwiązania.

Dlaczego więc nie zaoferujesz przeprowadzenia tej analizy?

Jestem zaskoczony, że otrzymałeś tak uprzejmą odpowiedź!

Spójrzmy na to z ich punktu widzenia.

Z powodzeniem zarządzają trzydziestoletnim systemem z prawdopodobnie setkami tysięcy wierszy kodu, interfejsami do być może dwudziestu innych systemów, które ucieleśniają procesy biznesowe, które ewoluowały przez czterdzieści lat.

Są oni prawdopodobnie / mam nadzieję, że są ekspertami w swojej dziedzinie i jako taki uznaliby C ++ za krok od „języka wysokiego poziomu asemblera” IBM, aby nadać mu pełny tytuł. Język asemblera IBM jest niezwykle wydajny, a język „MACRO” to najlepsza implementacja języka wstępnego przetwarzania / języka szablonów.

Co pięć lat pojawi się propozycja zastąpienia ich systemu od czasu jego pierwszego wdrożenia. Niektóre zostałyby odrzucone po studium wykonalności, inne dotarłyby aż do etapu projektowania, zanim straciły budżet, inne mogły nawet dostać się do kodu i etapu testowania, zanim napotkają problemy z wydajnością i zostaną zachowane.

C ++ po prostu nie pomoże. W środowisku, w którym działa aplikacja, nie ma biblioteki graficznej. (Istnieje biblioteka graficzna 3270, ale jest mało prawdopodobne, aby była obsługiwana w C ++, ponieważ nikt jej nie używa, i istnieje pełna biblioteka klienta „X”, ale aby korzystać z niej, musisz być w innym środowisku).

Mają interfejs użytkownika, który nie jest doskonały, ale który jest dobrze znany i szybki. Doświadczony operator wypełni formularz trzykrotnie szybciej, używając zielonego ekranu zamiast równoważnego GUI. Ponadto mogą zwracać uwagę na klienta podczas pisania dotykowego.

Operatorzy ekranów będą potrzebować szkolenia bez względu na to, jakiego interfejsu używają, przekwalifikowanie wszystkich pracowników w celu korzystania z nowego i nieznanego interfejsu GUI byłoby ogromną pozycją w budżecie w porównaniu z samym szkoleniem nowych pracowników w starym, pracowitym systemie.

Miałem podobny problem kilka lat temu w BellSouth. Po prostu napisałem kod COBOL, aby skanować programy w języku asemblera bajt po bajcie, rozdzielać kody operacyjne i operandy, konwertować instrukcje rozgałęzień, aby przejść do instrukcji i konwertować instrukcje porównania na IF. Ten program przekonwertował instrukcje DC na równoważny kod podziału danych COBOL i odpowiednio przekształcił ruchy, zaps itp.

Kiedy to zrobiłem, napisałem drugi program do konwersji IF i GOTO na IF-THEN, z ruchami itp. W liniach między tymi klastrami (nie było to wcale takie trudne - sekretem jest wstawienie IF i POZOSTAŁE, gdy ponownie przeczytasz kobol „pidgin” z pierwszej fazy od tyłu do przodu).

IF-THEN-ELSER szukał sytuacji, w których znalazł odniesienie GOTO w pobliżu etykiety, które można bezpiecznie usunąć (zmniejszając liczbę odnośników o 1). Uruchamiasz iteracyjnie ten program IF-THEN-ELSER (tzn. Uruchamiasz go wielokrotnie, zatrzymując się tylko wtedy, gdy ostatnie przejście nie może znaleźć sposobu na wprowadzenie dalszych zmian). Większość krytycznych prac jest wykonywana przez tego, który następnie, który, produkt COBOL, musi zostać dokładnie sprawdzony i sprawdzony przez doświadczonego, kompetentnego programistę w języku asemblera (a mianowicie mnie). Z mojego doświadczenia wynika, że ​​mój „jeśli-wtedy-elser” był w stanie wyeliminować ponad 90 procent GO TO wynikających z oryginalnej instrukcji oddziału.

Podejrzewam, że można przejść od tego momentu z prostą konwersją do C (lub C ++) - języków, z którymi też się znam. Jednak w BellSouth naszym wybranym językiem docelowym był COBOL / II. Zawsze występuje pewna złożoność, która wynika z sytuacji, w których pozostała etykieta ma wiele referencji GO TO (wiele razy sytuacje te są obsługiwane przez COBOL PERFORMs, ale czasami mogą być po prostu reprezentowane przez konstrukcje OR i AND).

Myślę, że miło jest tworzyć kod w elegancko skonstruowanym bloku COBOL / II z EVALUATE (konstrukcje Case) i 88-poziomowymi nazwami warunków. Dodanie tych drobnych poprawek doprowadziło do powstania kolejnej pary programów, które okazały się przydatne w programach COBOL niepochodzących z programów przekonwertowanych z asemblera.

Nie wiem czy to pomaga.

Jak zauważyli inni powyżej, proces ten należy przeprowadzić ostrożnie. Pomaga mieć 10-12 lat doświadczenia w kodowaniu asemblera, informującym o twoich procesach decyzyjnych. My, którzy mamy takie doświadczenie, trudno jest znaleźć.

Na koniec: pisaliśmy wtedy w asemblerze, ponieważ kompilatory dla języków wysokiego poziomu produkowały kłopotliwy, nieefektywny kod obiektowy. Dzisiejsze „optymalizujące” kompilatory COBOL nie mają tych samych złych nawyków. ----------

Rady Joela są generalnie solidne, ale w tym przypadku kompletne przepisanie jest spóźnione. Najlepiej, przerób przepis na pole bitwy, ponieważ masz do czynienia z potworem.

Nie jestem pewien, co dokładnie dodać, ponieważ sam już argumentowałeś za tym przepisem. Moim jedynym zaleceniem byłoby całkowite pominięcie C ++ i przejście bezpośrednio do interfejsu internetowego dla systemu wynajmu, ponieważ prawdopodobnie będzie to jeszcze łatwiejsze do przeszkolenia pracowników i pozwoli ci zaoszczędzić dużo pracy na interfejsie użytkownika (a także zrobić znacznie łatwiej jest zdobyć nową krew w projekcie, a nawet zlecić całość).

Co do istniejących programistów COBOL - być może mogą pomóc w udokumentowaniu istniejącego systemu oraz w procesie migracji.

Jeśli chodzi o aspekt techniczny, wiele będzie zależeć od jakości - modułowości - kodu asemblera. Niektórzy programiści rozumieli znaczenie tworzenia modułów o określonej, ograniczonej funkcji i przejrzystym, prostym parametryzowanym interfejsie, przy użyciu standardowych konwencji łączenia podprogramów IBM. Ogromna większość miała jednak tendencję do tworzenia monolitycznych potworności.

W tym pierwszym przypadku ponowne użycie jest możliwe i nie powinno być trudno wypracować „klej” między C ++ a asemblerem, zakładając, że moduły asemblera używają standardowych (lub przynajmniej spójnych) sekwencji wywołujących. Jednak najprawdopodobniej kod asemblera będzie bałaganem. Chociaż możliwe było napisanie asemblera strukturalnego, zrobiło to bardzo niewiele osób i prawie niemożliwe będzie rozpoznanie jakiegokolwiek „projektu”, od którego można zacząć przepisywanie.

Z drugiej strony, asembler 360/370 jest dość wysokim poziomem w porównaniu do dzisiejszych mikroprocesorów i jest o wiele prostszy, a C jest czasem uważany za „asembler wysokiego poziomu”. Pracowałem dla firmy DBMS, której produktem był w całości asembler 370, a nasz główny architekt uważał, że możliwe będzie automatyczne tłumaczenie kodu asemblera na C (w celu przyszłej przenośności). Jestem sceptyczny, ale chodzi o to, że odległość nie jest tak duża, jak mogłoby się wydawać.

Nie wiem, czy coś z tego jest pomocne. Jak mówię, myślę, że jest to w dużej mierze zależne od jakości i wielkości oryginalnego kodu.

Nie wiem, czy to żart, czy nie - Twoja firma poważnie stosuje kod napisany 39 lat temu? Jeśli działa na System / 360, będziesz musiał skompilować g ++ ze źródła ...

Szczerze mówiąc, nawet nie pomyślałbym o użyciu starego kodu; musisz przyjąć nowe podejście, usiąść i pomyśleć o tym, co należy wprowadzić do projektu, i zrobić to od podstaw. Tak, będzie to wymagało sporo planowania, ale nie sądzę, że nawet Joel powiedziałby, że jest to przypadek wprowadzania stopniowych zmian.

Jeśli chodzi o przekonanie firmy, że musisz się zmienić, musisz wskazać konkretne powody, które poprawią wydajność, doprowadzą do obniżenia kosztów i / lub pokażą, że to, czego używasz teraz, ma teraz negatywny wpływ na wynik finansowy.

Jeszcze jeden komentarz - wyobrażam sobie, że inne firmy wynajmujące samochody dołączyły do ​​nas w XXI wieku; Zrobiłbym trochę rekonesansu, aby zobaczyć, jak sobie z tym radzą (wyobrażam sobie, że jest oparty na sieci), i ewentualnie modeluję go na podstawie jednego z tych systemów (tj. Nie wymyślaj ponownie koła).

Powodzenia!

Teoretycznie przekonanie wyższej kadry kierowniczej do zastąpienia starego systemu nie powinno być trudne, jeśli pokażesz im, że zaoszczędzi im to megabuck. I tak będzie. Znalezienie programistów do obsługi tego systemu będzie coraz trudniejsze, a programiści będą coraz drożsi. To nie jest kwestia „kiedy”, to kwestia „kiedy”. To naprawdę musi zostać zaktualizowane.

Pytanie brzmi jednak, czy możesz przekonać ich nie tylko, że wymaga aktualizacji (i prawdopodobnie i tak o tym wiedzą), ale że powinien to być projekt wewnętrzny. Zwłaszcza jeśli zespół jest tylko tobą. Dość często tak poważny zamiennik jest zlecany na zewnątrz. Może być nawet dostępne gotowe oprogramowanie do rozważenia. Te opcje należy zbadać, a menedżerowie nalegają, aby tak się stało, jeśli są rozsądne.

Jeśli chodzi o to zadanie, jeśli byś to zrobił, tak naprawdę uważam, że w tym przypadku właściwe może być przepisanie buldożera. Argument Joela nie ma zastosowania w każdym przypadku. Jednak tak naprawdę nie mogłem wiedzieć, nie widząc tego.

1. Przyrostowa zmiana nie wchodzi w rachubę.

2. Prawdopodobnie będzie dostępne gotowe rozwiązanie. Istnieje wiele wypożyczalni samochodów.

3. Jeśli w ostateczności musisz go przepisać, najpierw poświęć trochę czasu na zastanowienie się, jak będzie działał nowy system.
   Po zidentyfikowaniu funkcjonalności i interfejsów możesz wybrać narzędzia programistyczne, które najlepiej pasują do potrzeb (i twoich umiejętności).

Jedną ze strategii minimalizacji stresu dla użytkowników końcowych jest rozpoczęcie emulacji starego brzydkiego interfejsu, który znają użytkownicy, z kilkoma drobiazgami, takimi jak listy rozwijane dla brzydkich mnemoników, a następnie stopniowe dodawanie funkcjonalności interfejsu użytkownika i odstawianie go do nowoczesnego interfejsu użytkownika.

Prawdopodobnie nie chcesz zachować tego samego formatu pliku danych, więc nie będzie powrotu po zmianie.