迁移COBOL代码 [英] migrate COBOL code

问题描述

我有一个将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.

谢谢..

推荐答案

迁移从一种语言或操作环境到另一种语言的软件系统始终是一个挑战。以下是
a需要考虑的一些事情：

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

• 由于
  长，传统代码的结构往往较差快速修复和问题解决方法的历史记录。试图扭曲实际情况时，这确实提高了信噪比
  。


• 转换代码会导致$ b进一步解构 $ b补偿源和
  目标实现平台之间的不匹配。当您从结构不良的基础（旧式系统）开始时，
  的最终结果可能是完全难以理解的。


• 通常会记录旧架构和/或业务流程到目前为止，
  的日期远比没有用的要糟，它实际上可能会误导人。


• COBOL代码的复杂度几乎总是被低估了。


• 许多功能将被发布到转换后的系统中，这些功能最初是为了补偿一次无法完成的事情而建造的
  （由于记忆较小，
  较慢的计算机等）。现在，其中许多可能都是非问题，您真的不希望它们。


• 没有明显或直接的方法可以将遗留过程驱动的
  系统重构为同等功能面向对象的系统（至少不是有意义的方式）。

• 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).

已经有成功的项目将COBOL直接迁移到Java中。请参见 naca 。
但是，最终结果只是其母亲（或另一位COBOL程序员）可能喜欢的东西，查看此讨论

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

通常，我会对任何提出将您的产品或服务转换为产品的产品或工具表示怀疑除了另一个版本的COBOL（例如COBOL.net）外，COBOL的
旧系统都可以使用。为此，您最终还是要使用本质上是COBOL系统的
。如果这种方法可以接受，那么您
可能希望查看此

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.

恕我直言，取代COBOL的最佳选择是重新设计系统。如果您发现
a的银弹可以从您所处的地方到想要成为的地方-写一本书，成为
a的顾问，并赚取数百万美元。

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.

这篇关于迁移COBOL代码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！