迁移 COBOL 代码

发布于 2024-09-16 04:26:38 字数 108 浏览 7 评论 0原文

我的任务是将 COBOL 代码转换为 .NET。有可用的转换器吗?我正在尝试高层次地理解 COBOL 代码。我无法理解 COBOL 代码。有没有流程图生成器?我很感激任何帮助。

谢谢..

I have a task to convert COBOL code to .NET. Are there any converters available? I am trying to understand COBOL code in high level. I have a trouble understanding the COBOL code. Is there any flowchart generators? I appreciate any help.

Thank you..

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

强者自强 2024-09-23 04:26:38

将软件系统从一种语言或操作环境迁移到另一种语言或操作环境始终是一个挑战。这里有
需要考虑的一些事情:

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

已经有成功的项目将 COBOL 直接迁移到 Java 中。请参阅 naca
然而,最终结果只是它的母亲(或其他 COBOL 程序员)可能喜欢的东西查看此讨论

一般来说,我会对任何声称可以转换 COBOL 遗产的产品或工具表示怀疑
系统到任何其他版本的COBOL(例如COBOL.net)。为此你还
最终得到本质上是 COBOL 系统。如果这种方法可以接受,那么您
可能需要查看此白皮书微焦点。

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

很抱歉提供了如此否定的答案,但如果您正在处理任何事情
但对于一个微不足道的遗留系统来说,解决这个问题绝非易事。

注意:不必费心绘制现有系统的流程图。尝试掌握流程输入/输出以及程序到程序的数据转换和流程。这里你需要了解的是业务功能,而不是它的具体实现。

Migrating software systems from one language or operating environment to another is always a challenge. Here are
a few things to consider:

  • Legacy code tends to be poorly structured as a result of a
    long history of quick fixes and problem work-arounds. This really ups the signal-to-noise ratio
    when trying to warp your head around what is really going on.
  • Converting code leads to further "de-structuring"
    to compensate for mis-matches between the source and
    target implementation platforms. When you start from a poorly structured base (legacy system),
    the end result may be totally un-intelligible.
  • Documentation of the legacy architecture and/or business processes is generally so far out of
    date that it is worse than useless, it may actually be misleading.
  • Complexity of COBOL code is almost always under estimated.
  • A number of "features" will be promulgated into the converted system that were originally
    built to compensate for things that "couldn't be done" at one time (due to smaller memories,
    slower computers etc.). Many of these may now be non-issues and you really don't want them.
  • There are no obvious or straight forward ways to refactor legacy process driven
    systems into an equivalent object oriented system (at least not in a meaningful way).

There have been successful projects that migrated COBOL directly into Java. See naca.
However, the end result is only something its mother (or another COBOL programmer) could love, see this discussion

In general I would be suspicious of any product or tool making claims to convert your COBOL legacy
system into anything but another version of COBOL (e.g. COBOL.net). To this end you still
end up with what is essentially a COBOL system. If this approach is acceptable then you
might want to review this white paper from Micro Focus.

IMHO, your best bet for replacing COBOL is to re-engineer your system. If you ever find
a silver bullet to get from where you are to where you want to be - write a book, become
a consultant and make many millions of dollars.

Sorry to have provided such a negative answer, but if you are working with anything
but a trivial legacy system, the problem is going to be anything but trivial to solve.

Note: Don't bother with flowcharting the existing system. Try to get a handle on process input/output and program to program data transformation and flow. You need to understand the business function here, not a specific implementation of it.

番薯 2024-09-23 04:26:38

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/概述

Micro Focus and Fujitsu both have COBOL products that work with .NET. Micro Focus allow you to download a product trial, while the Fujitsu NetCOBOL site has a number of articles and case studies.

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

假装不在乎 2024-09-23 04:26:38

[注:我在 Micro Focus 工作]

嗨,

实际上,在 .NET 框架上提供 COBOL 应用程序非常简单(与早期响应之一中的主张相反)。 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 中使用现有代码而不进行任何更改。

[Note: I work for Micro Focus]

Hi

Actually, making COBOL applications available on the .NET framework is pretty straightforward (contrary to claim made in one of the earlier responses). Fujitsu and Micro Focus both have COBOL compilers that can create ILASM code for execution in the CLR.

Micro Focus Visual COBOL (http://www.microfocus.com/visualcobol) makes it particularly easy to deploy traditional, procedural COBOL as managed code with full support for COBOL data types, file systems etc. It also includes an updated OO COBOL syntax that takes away a lot of the verbosity & complexity of the syntax to be very easy to write COBOL code based on C# examples. It's unique approach also makes it easy to use all the Visual Studio tools such as IntelliSense.

The original question mentioned "convert" and I would strongly recommend against any approach that requires the source code to be converted to some other language before being used in a .NET environment. The amount of effort and risk involved is highly unlikely to be worth any benefits accrued. On the contrary, keeping the code in COBOL maintains the existing, working code and allows for the option to deploy onto other platforms in the future. For example, how about having a single set of source code and having the option to deploy into .NET as a native language and into a Java environment without changing a line of source code?

I recommend you get a trial copy of Visual COBOL from the link above and see how you can use your existing code in .NET without making any changes.

陪我终i 2024-09-23 04:26:38

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

我相信 COBOL 编译器实际上可以编译 .NET 字节码,但它们有自己的运行时库来管理所有这些。也许值得考虑其中一个编译器,并将遗留代码保留在 COBOL 中。

除此之外,逐行翻译可能是不可能的。查看更高级别的代码并一次翻译代码块(例如,在过程级别或什至更高级别)。

This is not an easy task. COBOL has fundamental ideas about data types that do not map well with the object-oriented .NET framework (e.g. in COBOL, all data types are represented in terms of fixed-size buffers) and in particular the way groups and arrays work do not map well to .NET classes.

I believe there are COBOL compilers that can actually compile .NET bytecode, but they would have their own runtime libraries to manage all of that. It might be worth looking at one of these compilers and simply leaving the legacy code in COBOL.

Other than that, line-by-line translation is probably not possible. Look at the code at a higher level and translate blocks of code at a time (e.g. at the procedure level or even higher).

向日葵 2024-09-23 04:26:38

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

第一个是迁移到新环境,并通过一些小的修改保存现有的 COBOL 代码 (NET Microfocus COBOL);

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

当您迁移到“纯”NET/Java 代码并享受新环境的所有优势时,第三种方法是最有价值的一种。方便日后维护和开发。

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

然而,将钱投资于现代环境中的未来增长,比把钱花在旧技术的“模拟”上更好。

There are a lot mechanisms how to convert COBOL to modern scalable environments, such as .NET or Java.

The first is a migration to a new environment with saving the existing COBOL code with some minor modifications (NET Microfocus COBOL);

The second is a migration to a new platform with simulation of COBOL statements and constructions. When there are some additional NET/Java libraries to simulate some specific COBOL logic:
ACCEPT goes to NETLibrary.Accept and so on.

The third approach is the most valuable one, when you migrate to "pure" NET/Java code with all the benefits of the new environment. It can be easily maintained and developed in the future.

However, the unique expertise and toolkits are required for this approach, and there are only a few players on the global market that can help you in this case.
If we are talking about automatic migration, the number of players decreases greatly and, unfortunately for you, you have to pay for the specific technologies and tools (like ours).

However, it is a better idea to invest your money in your future growth in the modern environment, than to spend your money on the "simulation" of old technologies.

原野 2024-09-23 04:26:38

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

Translations is not an easy task. Besides Micro Focus and Fujitsu there is also Raincode that offers a free version of Cobol that nicely integrates with Visual Studio.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文