Przeprowadzka poza Itanium

Question

Obecnie mamy dużą aplikację o znaczeniu krytycznym, napisaną w języku COBOL, działającą na OpenVMS (Integrity/Itanium).

W miarę upływu miesięcy coraz więcej spekulacji na temat okresu użytkowania architektury Itanium. Oczywiście nic nie jest powiedziane, ale artykuły takie jak this i this tworzą niepokojący obraz. Chociaż nie mogę znaleźć nic oficjalnego do poparcia tego, są nawet szmery w korytarzach naszej firmy HP rezygnując z OpenVMS i HP COBOL wraz z nim.

Nie mogę uwierzyć, że jesteśmy sami w tym.

Tak jak ja to widzę, istnieje kilka możliwości:

1. emuluje niektóre starego sprzętu i uruchomić aplikację na które przy użyciu produktu jak CHARON-VAX lub CHARON-AXP. Sposób, w jaki to widzę, polega na tym, że proces ten powinien być względnie bezbolesny, szczególnie jeśli użyto opcji 64-bitowej (AXP). Potencjalne minusy to pogorszenie wydajności (chociaż powinno to zostać zrównoważone przez szybszy i szybszy sprzęt);
2. Przenieś aplikację opartą na HP COBOL do bardziej nowoczesnego dialektu języka COBOL, na przykład Visual COBOL. Zalety to fakt, że wysiłek przenoszenia jest stosunkowo niski (nadal jest to COBOL) i fakt, że można uruchomić aplikację na platformie Unix lub Windows. Wady są takie, że chociaż przenosisz COBOL, fakt, że przenosisz się do innego systemu operacyjnego może sprawić, że będzie to trudne (szczególnie, jeśli istnieją zależności zależne od OpenVMS);
3. Automatyczne przekształcanie języka COBOL w bardziej nowoczesny język, taki jak Java. Ma to oczywistą zaletę natychmiastowego uwolnienia jednego ze wszystkich starszych problemów za jednym zamachem: wsparcie sprzętowe, wsparcie systemu operacyjnego, a zwłaszcza znalezienie administratorów i programistów. Oprócz tego, że jest to duża praca, oczywistym minusem jest fakt, że skończy się nie-idiomatyczną Javą (lub jakikolwiek inny docelowy język zostanie ostatecznie wybrany); prawdopodobnie jest to coś, co można z czasem poprawić.
4. Przepisywanie od podstaw (oczywiście przy użyciu nowoczesnych technologii). Każdy, kto to zrobił, wie, jak drogie i czasochłonne jest to. Zawarłem tylko to, aby lista była kompletna :)

Należy zauważyć, że nie ma zależności od zastrzeżonego systemu DBMS; baza danych jest oparta na pliku ISAM.

... Więc moje pytanie brzmi:

Jakie są inni obliczu nieuchronne starzenie Itanium robi, aby utrzymać ciągłość biznesową, gdy ich platforma z wyboru jest OpenVMS i COBOL?

UPDATE:

Mamy już oficjalną gwarancję z naszym lokalnym przedstawicielem firmy HP, które będą obsługiwane Integrity/Itanium/OpenVMS przynajmniej aż do roku 2022. Myślę, że to oznacza, że ​​ta cała sprawa jest mniej o platforma, a więcej o języku (COBOL).

Answer 1

Głównym problemem związanym z tym wysiłkiem będą fragmenty kodu, które są specyficzne dla OpenVMS. Większość aplikacji opracowanych na OpenVMS zazwyczaj korzysta z procedur i procedur, które nie są łatwo przenoszone na inną platformę. Zamiast martwić się o specyficzną kompatybilność językową, początkowo skupiłbym się na procedurach runtime i procedurach poleceń używanych przez aplikację.

Alternatywnym podejściem może być dalsze korzystanie z bieżącej aplikacji podczas opracowywania nowej lub modyfikowanie komercyjnie dostępnej aplikacji do własnych potrzeb. O ile chodzi o długoterminowy status Itanium, historia wskazuje, że OpenVMS pozostanie opłacalny przez jakiś czas. Wciąż są używane maszyny VAX do zastosowań o znaczeniu krytycznym. Fakt, że OpenVMS i jego sprzęt są stabilne, jest główną przyczyną jego długowieczności.

Dan

Answer 2

Wygląda COBOL jest głównym zależność utrzymuje, że jest zaniepokojony. Rozumiem, że Itanium + OpenVMS na tym zdjęciu to tylko platforma.

Zdecydowanie nie jesteś sam, posługując się krytycznymi dla misji materiałami na OpenVMS. Witryna firmy HP zawiera mapę drogową OpenVMS (zarówno w wersji Alpha, jak i Integrity), a wsparcie trwa obecnie do 2015 roku. Oracle stara się ostatnio wykorzystać swój zasób SUN w różnych domenach.

W każdym razie, jeśli twoje obawy są poważne (na pewno wszyscy martwią się o COMPAQ, potem HP, vax >> alpha >> przejścia Itanium w przeszłości), jest czas, aby odłączyć zależność COBOL.

Chciałbym teraz zajrzeć do wykresu ścieżki migracji z COBOL na bardziej przenośny wybrany język (np. C/C++ ANSII bez rozszerzeń platformy). Być może Java nie jest najrozsądniejszym wyborem, biorąc pod uwagę działalność Oracle. Ponowne napisanie, jak nieprzyjemne jest, będzie bardziej progresywne i prawdopodobnie usprawni cały proces. Im szybciej się zacznie, tym szybciej się zakończy.

Ponadto, oprócz emulatorów, wciąż jest mnóstwo sprzętu używanego. Jak na ironię, jedna z firm, którą znam, właśnie teraz - w platformach integracyjnych, aby wyprzeć krytyczne dla ominięcia Alphas - domyślam się, że to "korporacyjne wymagania testowe" ...

Nic nie jest również rozwiązaniem, choć oczywiście bardziej ryzykowne: Platformy OpenVMS sprawdzają się jako niezawodne, więc alternatywnie, znalezienie wiarygodnej firmy pomocniczej innej firmy może zwiększyć przyszłą awarię sprzętu.

Answer 3

Tegoroczna edycja Rolling Roadmap sprawia, że ​​portowanie z OpenVMS wygląda jak doskonały pomysł.

Biorąc pod uwagę, ile COBOL istnieje na świecie, znalezienie osób, które będą wspierać COBOL, nie będzie stanowić problemu w najbliższej przyszłości. Jak wspomniano powyżej, istnieją kompilatory COBOL na innych platformach. Problem leży w wywołaniach usług systemowych OpenVMS i rozszerzeniach językowych DEC, z których korzysta twoja aplikacja. Nie wspominasz, gdzie są przechowywane twoje dane, w najgorszym przypadku twój COBOL używa RMS. Istnieje firma, która zapewnia implementację wielu usług systemu OpenVMS na platformach Linux i Unix. Brak konieczności wymiany tych usług podczas przenoszenia do innego systemu operacyjnego może zmniejszyć złożoność. Sprawdź Sector7.com.