远离安腾

Question

我们目前有一个用COBOL编写的大型业务关键型应用程序,运行在OpenVMS(Integrity/Itanium)上.

随着时间的推移,人们越来越多地猜测Itanium架构的生命周期.在开放,当然,但就像文章没有提到了这个和这个画一个令人担忧的画面.虽然我找不到任何支持这一点的官方消息,但我们惠普公司的走廊甚至还有嘀咕着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. 从头开始重写(当然,使用现代技术).任何做过此事的人都知道这是多么昂贵和耗时.我只是把它包括在内以使列表完整:)

请注意,不依赖于专有DBMS; 数据库是基于ISAM文件的.

所以...我的问题是:

当他们选择的平台是OpenVMS和COBOL时,Itanium即将淘汰以保持业务连续性的其他人面临着什么？

更新:

我们已经得到当地惠普代表的官方保证,至少在2022年之前我们将支持Integrity/Itanium/OpenVMS.我想这意味着整个问题不仅仅是关于平台,还有更多关于语言(COBOL)的问题.

Answer 1

这项工作的主要问题是 OpenVMS 特定的代码部分。大多数在 OpenVMS 上开发的应用程序通常使用不易移植到其他平台的例程和过程。我最初会关注应用程序使用的运行时例程和命令过程，而不是担心特定语言的兼容性。

另一种方法可能是继续使用当前应用程序，同时开发新应用程序或修改商用应用程序以满足您的需求。虽然安腾的长期地位受到质疑，但历史表明 OpenVMS 在未来一段时间内仍将保持可行。如今，VAX 机器仍然用于关键业务应用程序。OpenVMS 及其硬件的稳定性是其长寿的主要原因。

担