migrate COBOL code

Question

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

Her

There used to be flowchart generators on the market for COBOL programs but in truth they were often pretty useless unless the code you fed to them conformed to some very rigid standards - just set aside a day or so to learn to read the code, its not very hard. – Gutbucket

Good opportunity to Close this, Off Topic. tool request. Can't myself, as I flagged it for closure some long months ago :-) – Electroacoustics

Woohoo. I can vote to close on this again. – Electroacoustics

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

Mooncalf

Answer 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

Stymie

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

Subreption

I'm not so positive about "no benefits of converting the source code". However, I agree strongly with Mark, that if your organization has existing COBOL skills, that a .NET implementation of your COBOL applications makes a LOT of sense, and it is an option that should be seriously considered before thinking about a langauge conversion. – Flection

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

Rox

out of curiosity what blocks of code would be higher level than "Procedure"? – Gutbucket

@kloucks: There's actually no real "procedure" in COBOL. A COBOL program is broken up into SECTIONS, PARAGRAPHS and SENTENCES. A PARAGRAPH is kind of like a method or procedure and a SECTION is kind of like a module. It's possible to write your COBOL so that it works nothing like that, though, which is why automatic translation is very hard. – Rox

I thought you were referring to an application structure typified by this situation [ publib.boulder.ibm.com/infocenter/db2luw/v8/topic/… ] which I agree would be difficult to translate via a parser. translating a single program is usually only difficult when there is a lot of GOTO driven logic, a highly "structured" program is often pretty easy. – Gutbucket

@kloucks. At the risk of going off topic... I am not aware of any real differences between a COBOL SECTION and PARAGRAPH other than a PARAGRAPH is subordinate to a SECTION. See this question and if you are aware of anything significant, please post your answer there. The above IBM reference to "procedure" is in the context of a UDB stored procedure so is more relevant to UDB terminology than COBOL terminology. – Mooncalf

COBOL programs have SUBROUTINEs, just like every other modern language. The fact that COBOL programmers don't use them much is a different issue. – Flection

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

Palmy

Answer 6

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.

Tyrosine

It will definitely help with understanding the cobol code. – Tyrosine