远离安腾[关闭]答案

【问题标题】：Moving away from Itanium [closed]远离安腾[关闭]
【发布时间】：2025-12-02 23:00:02
【问题描述】：

我们目前有一个用 COBOL 编写的大型关键业务应用程序，在 OpenVMS（Integrity/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（或最终选择的任何目标语言）；可以说，随着时间的推移，这种情况可以得到改善。
从头开始重写（当然，使用现代技术）。做过这件事的人都知道这是多么昂贵和耗时。我只是将它包括在内以使列表完整:)

请注意，不依赖于专有 DBMS；该数据库是基于 ISAM 文件的。

所以……我的问题是：

当他们选择的平台是 OpenVMS 和 COBOL 时，面对 Itanium 即将过时的其他人如何保持业务连续性？

更新：

我们已从当地 HP 代表处获得官方保证，至少到 2022 年将支持 Integrity/Itanium/OpenVMS。我想这意味着整个问题与平台无关，以及有关语言 (COBOL) 的更多信息。

【问题讨论】：

这是一个丑陋的情况。我会尝试联系 MicroFocus，了解他们正在为客户开发什么样的迁移策略。我相信 MicroFocus 促进了 COBOL 应用程序向安腾平台的迁移。正因为如此，我怀疑他们会像任何人一样努力寻找从安腾到“下一个也是最伟大的事物”的迁移路径——不管那可能是什么。他们和其他人一样有很多事情要做，所以找出他们的船在哪里航行，也许可以搭便车。
看来您必须认真考虑离开 OpenVMS。您应该询问 HP 他们是否有支持 HP COBOL 的 UNIX 产品。另外，除了 NealB 的建议之外，您还应该咨询一下 Veryant，他们提供了两种不同的 COBOL 编译器 (veryant.com)

标签： cobol openvms itanium

【解决方案1】：

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

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

丹

【讨论】：

【解决方案2】：

看起来 COBOL 是让您担心的主要依赖项。我不明白这张图片中的 Itanium+OpenVMS 只是一个平台。

您绝对不是一个人在 OpenVMS 上运行关键任务的东西。 HP 网站有 OpenVMS 路线图（Alpha 和 Integrity），目前支持到 2015 年。Oracle 最近似乎试图在不同领域利用其 SUN 资产。

无论如何，如果您的担忧很大（当然我们都担心 COMPAQ，然后是 HP，vax>>alpha>>过去的 Itanium 过渡），是时候解开对 COBOL 的依赖了。

所以我现在会考虑绘制从 COBOL 迁移到更便携的语言选择的迁移路径（例如，没有平台扩展的 C/C++ ANSII）。考虑到甲骨文的活动，Java 可能不是最友好的选择。重写，多么不愉快，将更加进步，并且可能会简化整个过程。越早开始，越早完成。

另外，除了模拟器，还有很多二手硬件。具有讽刺意味的是，我刚刚认识的一家公司正在逐步采用 Integrity 平台来取代关键任务的 Alpha——我猜，这是“企业测试要求”……

什么也不做也是一种选择，但显然风险更大：OpenVMS 平台已被证明是可靠的，因此，寻找可靠的第三方支持公司可能会延长您未来的硬件应急能力。

【讨论】：

手工重写一个大型应用程序通常会导致灾难。它昂贵、难做、需要很长时间，而且新应用程序“永远不会”赶上正在运行的应用程序，因此无法取代它。如果你幸运的话，你可以克服这一切。实际可行的是大规模的自动迁移，从 COBOL-for-whatever-ecosystem（您的案例：OpenVMS）到 COBOL-for-different-ecosystem 和/或不同的语言。这些也很痛苦，但方式不同。见*.com/questions/3455456/…

【解决方案3】：

今年夏天的滚动路线图让移植 OpenVMS 看起来像是一个绝妙的主意。

鉴于世界上有多少 COBOL，在可预见的未来，寻找支持 COBOL 的人将不是问题。如上所述，其他平台上有 COBOL 编译器。问题在于您的应用程序使用的 OpenVMS 系统服务调用和 DEC 语言扩展。你没有提到你的数据存储在哪里，所以最坏的情况是你的 COBOL 使用 RMS。有一家公司在 Linux 和 Unix 上提供许多 OpenVMS 系统服务的实现。在移植到另一个操作系统时不需要替换这些服务可以降低复杂性。查看 Sector7.com。

【讨论】：

路线图 = EndoftheRoadmap