В настоящее время у нас есть большое критически важное для бизнеса приложение, написанное в COBOL, работающее на OpenVMS (Integrity/Itanium).Переход от Itanium
По мере прохождения месяцев все больше и больше размышлений о времени жизни архитектуры Itanium. Разумеется, ничего не говорится в открытом доступе, но такие статьи, как this и this, рисуют тревожное изображение. Хотя я не могу найти ничего официального, чтобы поддержать это, в коридорах нашей компании HP, занимающейся OpenVMS и HP COBOL, есть даже ропот.
Я не могу поверить, что мы одни в этом.
Как я вижу это, есть несколько вариантов:
- эмулировать некоторые старые аппаратные средства и запустить приложение на том, что, используя продукт как CHARON-VAX или CHARON-AXP. Как я вижу, профессионалы в том, что процесс должен быть относительно безболезненным, особенно если используется 64-разрядная (AXP) опция. Потенциальные недостатки - снижение производительности (хотя это должно быть компенсировано более быстрым и быстрым оборудованием);
- Поместите приложение на основе HP COBOL на более современный диалект COBOL, например Visual COBOL. В то же время плюсы - это тот факт, что усилия портирования относительно низки (это все еще COBOL) и тот факт, что можно запустить приложение на платформе Unix или Windows. Недостатком является то, что, хотя вы портируете COBOL, тот факт, что вы переносите в другую операционную систему, может сделать вещи сложными (особенно если существуют зависимости от OpenVMS);
- Автоматически переводить COBOL на более современный язык, такой как Java. Это дает очевидную выгоду от немедленного освобождения одного из всех устаревших вопросов одним махом: поддержка аппаратного обеспечения, поддержка операционных систем и особенно поиск администраторов и программистов. Помимо того, что это большая работа, очевидным недостатком является тот факт, что в итоге у вас будет неидиоматическая Java (или, в конечном счете, выбранный язык). возможно, это то, что может быть улучшено с течением времени.
- Переписывать с нуля (естественно, используя современные технологии). Любой, кто это сделал, знает, насколько это дорого и требует много времени. Я включил его только для того, чтобы сделать список полным :)
Обратите внимание, что нет никакой зависимости от проприетарной СУБД; база данных основана на базе ISAM.
Итак ... мой вопрос:
Какие другие сталкиваются с неизбежным устаревание Itanium делать, чтобы поддерживать непрерывность бизнеса, когда их выбор платформы является OpenVMS и COBOL?
UPDATE:
Мы провели официальную гарантию от нашего местного представителя HP, что Integrity/Itanium/OpenVMS будет поддерживать по крайней мере вплоть до 2022, я не думаю, это означает, что вся эта проблема меньше о платформу и многое другое о языке (COBOL).
Это уродливое положение. Я попробую связаться с MicroFocus, чтобы узнать, какую стратегию миграции они разрабатывают для своих клиентов. Я считаю, что MicroFocus способствовала миграции приложений COBOL на платформы Itanium. И из-за этого я подозреваю, что они будут работать так же сильно, как и все, чтобы найти путь миграции от Itanium к «следующей и самой лучшей вещи» - что бы это ни было. У них есть так много, чтобы потерять в этом, так как никто так узнает, где их корабль плывет и, может быть, поездка. – NealB
Похоже, вам придется серьезно подумать о том, чтобы отойти от OpenVMS. Вы должны спросить HP, есть ли у них продукт UNIX, который поддерживает HP COBOL. Кроме того, в дополнение к предложению NealB, вы также должны проверить с Veryant, они предлагают двух разных COBOL-compliers (http://www.veryant.com) – colemanj