我有一个任务是将COBOL代码转换为.NET。是否有任何可用的转换器？我试图在高层次上理解COBOL代码，但我有困难理解它。是否有任何流程图生成器？非常感谢任何帮助。
谢谢。
6个回答
11
将软件系统从一种语言或操作环境迁移到另一种始终是一个挑战。以下是需要考虑的几个问题：
在我看来，替换COBOL的最佳选择是重新设计您的系统。如果您找到了一个通向目标的灵丹妙药，请写一本书，成为顾问并赚取数百万美元。
很抱歉提供如此消极的答案，但如果您正在处理除微不足道的遗留系统以外的任何东西，那么解决问题将会非常困难。
注意：不要费力去绘制现有系统的流程图。尝试掌握过程输入/输出和程序到程序的数据转换和流动。您需要理解业务功能，而不是特定实现。
- 由于长期快速修复和问题解决，遗留代码往往结构较差。这真的增加了信号与噪声之比，使人们难以理解实际情况。
- 转换代码会导致进一步的“去结构化”，以弥补源实现平台与目标实现平台之间的不匹配。当你从一个结构不良的基础（遗留系统）开始时，最终结果可能完全无法理解。
- 遗留架构和/或业务流程的文档通常已经过时到比没有更糟，它可能会误导。
- COBOL代码的复杂性几乎总是被低估的。
- 许多“特性”将被推广到转换后的系统中，这些特性最初是为了弥补某些事情而构建的，这些事情曾经“无法完成”（由于内存较小，计算机速度较慢等）。其中许多现在可能已经不是问题，你真的不想要它们。
- 没有明显或简单的方法将遗留过程驱动的系统重构为等效的面向对象的系统（至少没有有意义的方法）。
已经有成功的项目将COBOL直接迁移到Java。请参见naca。然而，最终结果只是其母亲（或另一个COBOL程序员）能够喜欢的东西，参见此讨论。
一般来说，我会对声称将您的COBOL遗留系统转换为除COBOL之外的任何东西（例如COBOL.net）的任何产品或工具持怀疑态度。因此，您最终仍将拥有实质上的COBOL系统。如果这种方法可行，则您可能需要查看Micro Focus的白皮书。在我看来，替换COBOL的最佳选择是重新设计您的系统。如果您找到了一个通向目标的灵丹妙药，请写一本书，成为顾问并赚取数百万美元。
很抱歉提供如此消极的答案，但如果您正在处理除微不足道的遗留系统以外的任何东西，那么解决问题将会非常困难。
注意：不要费力去绘制现有系统的流程图。尝试掌握过程输入/输出和程序到程序的数据转换和流动。您需要理解业务功能，而不是特定实现。
- NealB
7
Micro Focus和Fujitsu都有可以与.NET兼容的COBOL产品。Micro Focus允许您下载产品试用，而Fujitsu NetCOBOL网站上有许多文章和案例研究。
Micro Focus：http://www.microfocus.com/products/micro-focus-developer/micro-focus-cobol/windows-and-net/micro-focus-visual-cobol.aspx Fujitsu：http://www.netcobol.com/products/Fujitsu-NetCOBOL-for-.NET/overview
Micro Focus：http://www.microfocus.com/products/micro-focus-developer/micro-focus-cobol/windows-and-net/micro-focus-visual-cobol.aspx Fujitsu：http://www.netcobol.com/products/Fujitsu-NetCOBOL-for-.NET/overview
- colemanj
3
[注意：我在Micro Focus工作]
您好
实际上，将COBOL应用程序提供给.NET框架非常简单（与早期回答中的某些声明相反）。Fujitsu和Micro Focus都有COBOL编译器，可以创建ILASM代码以在CLR中执行。
Micro Focus Visual COBOL (http://www.microfocus.com/visualcobol) 使得将传统的过程化COBOL部署为托管代码变得特别容易，并完全支持COBOL数据类型、文件系统等。它还包括一个更新的面向对象的COBOL语法，消除了大量冗长和复杂的语法，使得基于C#示例编写COBOL代码非常容易。它独特的方法也使得使用所有Visual Studio工具如智能感知非常容易。
最初的问题提到了“转换”，我强烈建议不要采用任何需要在.NET环境中将源代码转换为其他语言的方法。涉及的努力和风险高度不可能值得获得任何收益。相反，保持代码在COBOL中维护现有的工作代码，并允许在将来将其部署到其他平台的选项。例如，有一个单一的源代码集，并有将其作为本地语言部署到.NET和作为Java环境的选项而不改变任何源代码行的选项，如何？
我建议您从上面的链接中获取Visual COBOL的试用版，看看如何在.NET中使用现有代码而不进行任何更改。
- Mark
1
我对“不转换源代码没有好处”的说法并不太乐观。然而，我非常同意马克的观点，如果你的组织已经具备了 COBOL 技能，那么将 COBOL 应用程序实现为 .NET 应用程序是非常明智的选择，这是一种在考虑语言转换之前应该认真考虑的选项。 - Ira Baxter
2
这并不是一项容易的任务。COBOL有关于数据类型的基本思想，与面向对象的.NET框架不太相符（例如，在COBOL中，所有数据类型都以固定大小的缓冲区表示），尤其是组和数组的工作方式不太适合.NET类。
我相信有COBOL编译器可以实际编译.NET字节码，但它们会有自己的运行时库来管理所有这些内容。也许值得看看其中一个编译器，并简单地将遗留代码保留在COBOL中。
除此之外，逐行翻译可能不可能。从更高的层次上查看代码，并按块翻译代码（例如，在过程级别或更高级别）。
我相信有COBOL编译器可以实际编译.NET字节码，但它们会有自己的运行时库来管理所有这些内容。也许值得看看其中一个编译器，并简单地将遗留代码保留在COBOL中。
除此之外，逐行翻译可能不可能。从更高的层次上查看代码，并按块翻译代码（例如，在过程级别或更高级别）。
- Dean Harding
5
出于好奇，哪些代码块比“过程”更高级？ - kloucks
@kloucks：实际上，COBOL 中并没有真正的“过程”。COBOL 程序被分成 SECTIONS、PARAGRAPHS 和 SENTENCES。PARAGRAPH 类似于方法或过程，SECTION 类似于模块。当然，你也可以编写与此完全不同的 COBOL 程序，这就是为什么自动翻译非常困难的原因。 - Dean Harding
我以为你指的是这种情况下的应用程序结构[http://publib.boulder.ibm.com/infocenter/db2luw/v8/topic/com.ibm.db2.udb.doc/ad/c0010381.htm]，我同意这种情况下通过解析器进行翻译会比较困难。当一个程序有很多基于GOTO的逻辑时，翻译单个程序通常会很困难，而一个高度“结构化”的程序通常相对容易一些。 - kloucks
@kloucks。冒着偏离话题的风险...我不知道COBOL SECTION和PARAGRAPH之间除了PARAGRAPH从属于SECTION外是否有任何真正的区别。请参见此问题，如果您知道任何重要的内容，请在那里发布您的答案。上述IBM参考“procedure”的上下文是UDB存储过程，因此与UDB术语而非COBOL术语更相关。 - NealB
COBOL程序和其他现代语言一样有子程序。 COBOL程序员很少使用它们是另外一个问题。 - Ira Baxter
1
有许多机制可以将COBOL转换为现代可扩展环境，例如.NET或Java。
第一个方法是在进行一些小的修改（NET Microfocus COBOL）后，将现有的COBOL代码迁移到新环境中；
第二个方法是迁移到新平台，并模拟COBOL语句和结构。当有一些额外的NET/Java库以模拟特定的COBOL逻辑时：ACCEPT变成NETLibrary.Accept等等。
第三种方法是最有价值的，当您迁移到“纯”NET/Java代码时，可以获得新环境的所有优势。它可以轻松地在将来进行维护和开发。
然而，这种方法需要独特的专业知识和工具包，全球市场上只有少数几个参与者可以在这种情况下帮助您。 如果我们谈论自动迁移，参与者的数量会大大减少，不幸的是，您必须支付特定技术和工具（如我们所提供的）的费用。
然而，投资于未来增长的现代环境比花费金钱“模拟”旧技术更好的想法。
- Ispirer SQLWays Migrations
0
翻译并不是一项容易的任务。除了Micro Focus和Fujitsu之外，Raincode也提供了一个免费版本的Cobol，可以很好地与Visual Studio集成。
- cbmendes
1
这将有助于理解COBOL代码。 - cbmendes
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接