Отойдя от Itanium

Question

В настоящее время у нас есть большое критически важное для бизнеса приложение, написанное на языке COBOL, работающее на OpenVMS (Integrity/Itanium).

По прошествии нескольких месяцев все больше и больше разговоров о сроке службы архитектуры Itanium. Конечно, ничего не сказано открыто, но такие статьи и эта картина создают тревожную картину. Хотя я не могу найти ничего официального, чтобы поддержать это, даже в коридорах нашей компании HP рвется OpenVMS и HP COBOL вместе с ним.

Я не могу поверить, что мы одни в этом.

На мой взгляд, есть несколько вариантов:

1. Эмулируйте какое-то старое оборудование и запустите на нем приложение, используя такой продукт, как CHARON-VAX или CHARON-AXP. На мой взгляд, плюсы в том, что процесс должен быть относительно безболезненным, особенно если используется 64-битная опция (AXP). Потенциальные недостатки - снижение производительности (хотя это должно быть компенсировано более быстрым и быстрым оборудованием);
2. Перенесите приложение на основе HP COBOL на более современный диалект COBOL, например Visual COBOL. Таким образом, плюсы заключаются в том, что усилия по переносу данных относительно невелики (это все еще COBOL), и в том, что приложение можно запускать на платформе Unix или Windows. Недостатки в том, что, хотя вы портируете COBOL, тот факт, что вы портируете на другую операционную систему, может усложнить задачу (особенно если есть зависимости, специфичные для OpenVMS);
3. Автоматически переводите COBOL на более современный язык, такой как Java. Это имеет очевидное преимущество, заключающееся в том, что одним махом сразу освобождается от всех унаследованных проблем: поддержки оборудования, поддержки операционной системы и, особенно, поиска администраторов и программистов. Помимо того, что это большая работа, очевидным недостатком является тот факт, что в итоге получится не-идиоматическая Java (или любой целевой язык, который в конечном итоге будет выбран); возможно, это то, что можно улучшить со временем.
4. Переписать с нуля (естественно, с использованием современных технологий). Любой, кто сделал это, знает, насколько это дорого и требует много времени. Я только включил это, чтобы закончить список:)

Обратите внимание, что нет никакой зависимости от проприетарной СУБД; база данных основана на файлах ISAM.

Итак... мой вопрос:

Что другие сталкиваются с неизбежным устареванием Itanium, чтобы поддерживать непрерывность бизнеса, когда их платформой является OpenVMS и COBOL?

ОБНОВИТЬ:

Мы получили официальное заверение от нашего местного представителя HP, что Integrity/Itanium/OpenVMS будут поддерживаться, по крайней мере, до 2022 года. Я думаю, это означает, что весь этот вопрос связан не столько с платформой, сколько с языком (COBOL).

Answer 1

Главной проблемой в этом направлении будут части кода, специфичные для OpenVMS. Большинство приложений, разработанных на OpenVMS, обычно используют подпрограммы и процедуры, которые нелегко переносить на другую платформу. Вместо того, чтобы беспокоиться о совместимости конкретных языков, я бы изначально сосредоточился на подпрограммах времени выполнения и командных процедурах, используемых приложением.

Альтернативный подход может состоять в том, чтобы продолжать использовать текущее приложение при разработке нового или изменении коммерчески доступного приложения в соответствии с вашими потребностями. Хотя долгосрочный статус Itanium находится под вопросом, история показывает, что OpenVMS останется жизнеспособной в течение некоторого времени. Сегодня все еще используются машины VAX для критически важных бизнес-приложений. Тот факт, что OpenVMS и его оборудование стабильны, является основной причиной его долговечности.

Дэн

Answer 2

Похоже, COBOL - это основная зависимость, которая заставляет вас волноваться. Я не понимаю Itanium+OpenVMS на этой картинке - просто платформа.

Вы определенно не одиноки в критически важных задачах OpenVMS. Сайт HP имеет план OpenVMS (как Alpha, так и Integrity), поддержка которого в настоящее время распространяется до 2015 года. Похоже, Oracle в последнее время пытается использовать свой актив SUN в разных доменах.

В любом случае, если ваши опасения значительны (конечно, мы все беспокоились о COMPAQ, тогда HP, vax>>alpha>>Itanium переходы в прошлом), есть время, чтобы развязать зависимость COBOL.

Итак, я бы сейчас рассмотрел схему перехода от COBOL на более переносимый язык (например, C/C++ ANSII без расширений платформы). Возможно, Java не самый лучший выбор, учитывая активность Oracle. Перепишите, как это неприятно, будет более прогрессивным и, скорее всего, упростит весь процесс. Чем раньше начнется, тем быстрее завершится.

Кроме того, в дополнение к эмуляторам, есть еще много подержанного оборудования. По иронии судьбы, одна компания, которую я только что знаю, внедряет платформы Integrity, чтобы вытеснить критически важные программы Alphas - я полагаю, это "требования к корпоративному тестированию"...

"Ничего не делать" - это тоже вариант, хотя и явно более рискованный: доказано, что платформы OpenVMS надежны, так что в противном случае поиск надежной сторонней компании поддержки может продлить ваше будущее оборудование.

Answer 3

Rolling Roadmap этим летом делает портирование OpenVMS отличной идеей.

Учитывая, сколько COBOL существует в мире, поиск людей для поддержки COBOL не станет проблемой в обозримом будущем. Как отмечено выше, на других платформах есть компиляторы COBOL. Проблема заключается в вызовах системных служб OpenVMS и расширениях языка DEC, используемых вашим приложением. Вы не упоминаете, где хранятся ваши данные, поэтому в худшем случае ваш COBOL использует RMS. Есть компания, которая обеспечивает реализацию многих системных сервисов OpenVMS в Linux и Unixes. Отсутствие необходимости замены этих служб при переносе на другую операционную систему может снизить сложность. Проверьте Sector7.com.