cobol - 远离安腾

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

7年前关闭。




Improve this question




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

随着时间的推移，关于安腾架构的生命周期的猜测越来越多。当然，没有什么是公开的，但是像 this 这样的文章和 this描绘一幅令人担忧的图画。虽然我找不到任何官方支持这一点，但在我们公司的走廊里，甚至有人提示惠普放弃 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 时，其他人面临着 Itanium 即将过时的情况以保持业务连续性？

更新:

我们从本地惠普代表那里得到官方保证，Integrity/Itanium/OpenVMS 将至少支持到 2022 年。我想这意味着整个问题与平台无关，而与语言 (COBOL) 相关。

Answer 1

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

另一种方法可能是继续使用当前应用程序，同时开发新应用程序或修改商用应用程序以满足您的需要。虽然 Itanium 的长期地位存在问题，但历史表明 OpenVMS 将在 future 一段时间内保持活力。今天仍有 VAX 机器用于关键业务应用程序。 OpenVMS 及其硬件稳定的事实是其长寿的主要原因。

担