migrate COBOL code

问题:

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

回答1:

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.

回答2:

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

回答3:

[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.

回答4:

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

回答5:

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.