我们目前有一个用 COBOL 编写的大型关键业务应用程序,在 OpenVMS(Integrity/Itanium)上运行。
几个月过去了,关于安腾架构寿命的猜测越来越多。当然,没有什么是公开的,但是像这样和这样的文章描绘了一幅令人担忧的画面。虽然我找不到任何官方支持这一点,但在我们公司的走廊里,甚至还有 HP 抛弃 OpenVMS 和 HP COBOL 随之而来的抱怨。
我无法相信我们是孤独的。
在我看来,有几个选择:
- 使用CHARON-VAX或CHARON-AXP等产品模拟一些旧硬件并在其上运行应用程序。在我看来,优点是该过程应该相对轻松,尤其是在使用 64 位 (AXP) 选项的情况下。潜在的缺点是性能下降(尽管这应该被越来越快的硬件所抵消);
- 将基于 HP COBOL 的应用程序移植到更现代的 COBOL 方言,例如Visual COBOL。那么,优点在于移植工作量相对较低(仍然是 COBOL)以及可以在 Unix 或 Windows 平台上运行应用程序这一事实。缺点是虽然您正在移植 COBOL,但移植到不同操作系统的事实可能会使事情变得棘手(尤其是如果存在特定于 OpenVMS 的依赖项);
- 自动将 COBOL 翻译成更现代的语言,如 Java。这有一个明显的好处,即一举将一个人从所有遗留问题中解放出来:硬件支持、操作系统支持,尤其是寻找管理员和程序员。除了这是一项艰巨的工作之外,一个明显的缺点是最终会使用非惯用的 Java(或最终选择的任何目标语言)。可以说,随着时间的推移,这是可以改善的。
- 从头开始重写(当然,使用现代技术)。做过这件事的人都知道这是多么昂贵和耗时。我只是将它包括在内以使列表完整:)
请注意,不依赖于专有 DBMS;该数据库是基于 ISAM 文件的。
所以......我的问题是:
当他们选择的平台是 OpenVMS 和 COBOL 时,其他面临安腾即将过时的人如何保持业务连续性?
更新:
我们已经从当地惠普代表那里得到官方保证,至少在 2022 年之前将支持 Integrity/Itanium/OpenVMS 。我想这意味着整个问题与平台无关,而与语言(COBOL)有关。