迁移 COBOL 代码答案

【问题标题】：migrate COBOL code迁移 COBOL 代码
【发布时间】：2010-08-30 01:31:26
【问题描述】：

我的任务是将 COBOL 代码转换为 .NET。有没有可用的转换器？我试图从高层次上理解 COBOL 代码。我无法理解 COBOL 代码。有流程图生成器吗？感谢您的帮助。

谢谢你..

【问题讨论】：

市场上曾经有用于 COBOL 程序的流程图生成器，但实际上它们通常毫无用处，除非您提供给它们的代码符合一些非常严格的标准 - 只需留出一天左右时间学习阅读代码，并不难。
关闭此主题的好机会。工具请求。我自己不行，因为我在几个月前就将其标记为关闭 :-)
哇哦。我可以再次投票结束。

标签： cobol flowchart

【解决方案1】：

将软件系统从一种语言或操作环境迁移到另一种语言或操作环境始终是一项挑战。这里是需要考虑的几点：

由于快速修复和问题解决方法的悠久历史。这确实提高了信噪比当你试图绕开真正发生的事情时。
转换代码会导致进一步的“解构” 补偿源和之间的不匹配目标实施平台。当您从结构不佳的基础（遗留系统）开始时，最终结果可能完全无法理解。
遗留体系结构和/或业务流程的文档通常远远超出说它比没用更糟糕，它实际上可能具有误导性。
COBOL 代码的复杂性几乎总是被低估。
许多“功能”将发布到转换后的系统中旨在补偿一次“无法完成”的事情（由于较小的记忆，较慢的计算机等）。其中许多现在可能已经不是问题了，而您真的不想要它们。
没有明显或直接的方法来重构遗留的流程驱动系统转换为等效的面向对象系统（至少不是以有意义的方式）。

已经有成功的项目将 COBOL 直接迁移到 Java。见naca。然而，最终结果只是它的母亲（或其他 COBOL 程序员）可能会喜欢的东西，see this discussion

一般来说，我会怀疑任何声称转换您的 COBOL 遗产的产品或工具除了 COBOL 的另一个版本（例如 COBOL.net）之外的任何东西。为此你还最终得到本质上是一个 COBOL 系统。如果这种方法是可以接受的，那么你可能想要查看来自 Micro Focus 的 white paper。

恕我直言，替换 COBOL 的最佳选择是重新设计您的系统。如果你发现从你所在的地方到你想去的地方的灵丹妙药——写一本书，成为一名顾问并赚了数百万美元。

很抱歉提供了这样一个否定的答案，但是如果您正在处理任何事情但是一个微不足道的遗留系统，这个问题将是一件很容易解决的事情。

注意：不要为现有系统的流程图而烦恼。尝试处理流程输入/输出和程序以编程数据转换和流。这里需要了解业务功能，而不是具体的实现。

【讨论】：

【解决方案2】：

Micro Focus 和 Fujitsu 都有与 .NET 兼容的 COBOL 产品。 Micro Focus 允许您下载产品试用版，而 Fujitsu NetCOBOL 网站上有大量文章和案例研究。

微焦点 http://www.microfocus.com/products/micro-focus-developer/micro-focus-cobol/windows-and-net/micro-focus-visual-cobol.aspx

富士通 http://www.netcobol.com/products/Fujitsu-NetCOBOL-for-.NET/overview

【讨论】：

【解决方案3】：

[注意：我为 Micro Focus 工作]

嗨

实际上，使 COBOL 应用程序在 .NET 框架上可用是非常简单的（与早期响应之一中的说法相反）。 Fujitsu 和 Micro Focus 都有 COBOL 编译器，可以创建 ILASM 代码以在 CLR 中执行。

Micro Focus Visual COBOL (http://www.microfocus.com/visualcobol) 使得将传统的过程 COBOL 部署为托管代码变得特别容易，并完全支持 COBOL 数据类型、文件系统等。它还包括更新的 OO COBOL 语法，可以减少很多语法的冗长和复杂性非常容易基于 C# 示例编写 COBOL 代码。它的独特方法还可以轻松使用所有 Visual Studio 工具，例如 IntelliSense。

最初的问题提到了“转换”，我强烈建议不要使用任何需要将源代码转换为其他语言才能在 .NET 环境中使用的方法。所涉及的努力和风险极不可能值得任何收益。相反，将代码保留在 COBOL 中可以维护现有的工作代码，并允许将来选择部署到其他平台上。例如，拥有一组源代码并可以选择将 .NET 作为本地语言部署到 Java 环境中而不更改源代码行？

我建议您从上面的链接中获取 Visual COBOL 的试用版，看看如何在不进行任何更改的情况下在 .NET 中使用现有代码。

【讨论】：

我对“转换源代码没有好处”不太乐观。但是，我非常同意 Mark 的观点，即如果您的组织拥有现有的 COBOL 技能，那么您的 COBOL 应用程序的 .NET 实现非常有意义，并且在考虑语言转换之前应该认真考虑这个选项。

【解决方案4】：

这不是一件容易的事。 COBOL 对不能很好地与面向对象的 .NET 框架映射的数据类型有基本的想法（例如，在 COBOL 中，所有数据类型都用固定大小的缓冲区表示），特别是组和数组的工作方式不能映射.NET 类。

我相信有一些 COBOL 编译器可以实际编译 .NET 字节码，但它们会有自己的运行时库来管理所有这些。可能值得查看其中一个编译器并将遗留代码留在 COBOL 中。

除此之外，可能无法进行逐行翻译。查看更高级别的代码并一次翻译代码块（例如在过程级别甚至更高级别）。

【讨论】：

出于好奇，哪些代码块会比“Procedure”级别更高？
@kloucks：COBOL 中实际上没有真正的“程序”。 COBOL 程序被分解为 SECTIONS、PARAGRAPHS 和 SENTENCES。 PARAGRAPH 有点像方法或过程，而 SECTION 有点像模块。但是，可以编写 COBOL 使其完全不工作，这就是自动翻译非常困难的原因。
我以为您指的是这种情况 [publib.boulder.ibm.com/infocenter/db2luw/v8/topic/…] 所代表的应用程序结构，我同意这很难通过解析器进行翻译。翻译单个程序通常只有在有大量 GOTO 驱动逻辑时才会困难，而高度“结构化”的程序通常很容易。
@kloucks。冒着偏离主题的风险......我不知道 COBOL SECTION 和 PARAGRAPH 之间的任何真正区别，除了 PARAGRAPH 从属于 SECTION。请参阅this question，如果您知道任何重要的事情，请在此处发布您的答案。上述 IBM 对“过程”的引用是在 UDB 存储过程的上下文中，因此与 UDB 术语的相关性高于 COBOL 术语。
COBOL 程序有子程序，就像所有其他现代语言一样。 COBOL 程序员不经常使用它们的事实是一个不同的问题。

【解决方案5】：

有很多机制可以将 COBOL 转换为现代可扩展环境，例如 .NET 或 Java。

第一个是迁移到新环境，通过一些小的修改保存现有的 COBOL 代码（NET Microfocus COBOL）；

第二个是迁移到具有 COBOL 语句和结构模拟的新平台。当有一些额外的 NET/Java 库来模拟一些特定的 COBOL 逻辑时： ACCEPT 转到 NETLibrary.Accept 等等。

第三种方法是最有价值的方法，当您迁移到“纯”NET/Java 代码并享受新环境的所有好处时。它可以很容易地在未来进行维护和开发。

但是，这种方法需要独特的专业知识和工具包，在这种情况下，全球市场上只有少数参与者可以为您提供帮助。如果我们谈论的是自动迁移，那么玩家数量会大大减少，不幸的是，您必须为特定的技术和工具（如我们的）付费。

但是，最好将钱投资于现代环境中的未来发展，而不是将钱花在“模拟”旧技术上。

【讨论】：

【解决方案6】：

翻译不是一件容易的事。除了 Micro Focus 和 Fujitsu，还有 Raincode，它提供了与 Visual Studio 完美集成的免费版 Cobol。

【讨论】：

它肯定有助于理解 cobol 代码。