远离安腾

Question

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

随着月份的推移，人们越来越多地猜测Itanium架构的生命周期。当然，没有什么是公开的，但像this和this这样的文章描绘了令人担忧的画面。虽然我找不到任何支持这一点的官方消息，但我们惠普公司的走廊里甚至还有嘀咕声，他们放弃了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即将淘汰以保持业务连续性还面临着什么？

更新：

我们当地惠普代表已​​得到官方保证，至少将支持至少至12022年。我想这意味着整个问题不是关于平台，以及关于语言的更多信息（COBOL）。

Answer 1

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

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

丹

Answer 2

看起来COBOL是让你担心的主要依赖。我在这张图片中看到的不安和Itanium + OpenVMS只是一个平台。

你绝对不是唯一一个在OpenVMS上运行关键任务的东西。惠普网站拥有OpenVMS路线图（包括Alpha和Integrity），支持目前延伸至2015年。甲骨文似乎最近试图利用它在不同领域的SUN资产。

在任何情况下，如果您的担忧很大（确定我们都担心COMPAQ，然后HP，vax＆gt;＆gt;＆gt;＆gt;过去的Itanium过渡），那么就有时间取消COBOL依赖关系。

所以我现在看看如何绘制从COBOL迁移到更易于选择的可移植语言的迁移路径（例如，没有平台扩展的C / C ++ ANSII）。考虑到Oracle的活动，Java可能不是最自由的选择。重写，它是多么令人不愉快，将更加进步，并可能简化整个过程。越早开始，越快完成。

此外，除了仿真器之外，还有大量的二手硬件。具有讽刺意味的是，我刚才知道的一家公司正在逐步采用Integrity平台来取代关键的Alphas - 我想，这是“公司测试要求”......

Do-nothing也是一种选择，虽然显然风险更大：OpenVMS平台被证明是可靠的，因此，寻找可靠的第三方支持公司可能会扩展您未来的硬件意外事件。

Answer 3

今年夏天的滚动路线图使得移植OpenVMS看起来是一个很好的主意。

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