Experience migrating legacy Cobol / PL1 to Java

Question

ORIGINAL Q: I wonder if anyone has any experience porting the large Cobol / PL1 codebase to Java?

How automated is the process and how supported was the exit?

How has the transition from transactional to OO changed?

Any lessons learned along the way, or resources / technical documents that may be beneficial, will be appreciated.

---

EDIT 7/7:. Of course, the NACA approach is interesting, the ability to continue making changes to the BAU in the COBOL code until the release of the JAVA version makes sense for any organization.

The argument for procedural Java in the same layout as COBOL, to give the coder a sense of comfort when familiarizing himself with the Java language, is a valid argument for a large organization with a large code base. As @Didier notes, annual savings of $ 3 million provide an opportunity for generous additions to any future BAU changes to reorganize the code on an ongoing basis. According to him, if you care about your people, you will find a way to preserve their happiness, gradually challenging them.

The problem, as I see it with a suggestion from @duffymo

It’s best to try and understand the problem at its roots and re-expression as an object-oriented system

is that if you have any changes in BAU, then during the life cycle of the LONG project to encode your new OO system, you end up coding and testing changes in double. This is the main advantage of the NACA approach. I had some experience porting Client-Server applications to a web implementation, and this was one of the main problems we encountered, constantly changing requirements due to BAU changes. He did PM and was planning a real challenge.

Thanks to @hhafez, whose experience is well perceived as "similar, but slightly different" and has a fairly satisfactory experience of automatically migrating code from Ada to Java.

Thanks @Didier for the contribution, I'm still exploring your approach, and if I have Q, I will give you a line.

Answer 1

Update 6/25: A friend just stumbled upon the NACA Cobol to Java Converter. It looks pretty interesting, it was used to translate the 4-meter Cobol lines with 100 percent accuracy. Here is the NACA open source project page . Other converters that I saw were patented, and there was clearly no success story or detailed sample code on the materials. NACA is worth a long look.

Update 7/4: @Ira Baxter reports that Java output looks very Cobol-esque, which it absolutely does. For me, this is a natural result of automatic translation. I doubt that we will ever find a much better translator. Perhaps this is due to gradual rewriting.

Update 2/7/11: @spgennard indicates that there are Cobol compilers on the JVM, for example Veryant isCobol Evolve . They can be used to gradually transition the codebase, although I think the OP was more interested in automatically converting the source.

---

I would be very careful about that. (I worked for a company that automatically fixed Cobol and PL / I programs for Y2K, and made a front-end compiler that converted many Cobol dialects to our intermediate analytical form, as well as a code generator.) I believe you’d end with a Java code base that will still be ineffective and unsatisfactory. You may encounter performance issues, dependencies on vendor-supplied libraries, generated code errors, etc. You will surely take a huge test bill.

From scratch, with a new object-oriented design, the right approach may be, but you must also carefully consider the decades of stored knowledge represented by the code base. Often there are many subtleties that your new code may miss. On the other hand, if you find it difficult to find staff to support an outdated system, you may not have a choice.

One step-by-step approach would be to upgrade to Cobol 97 first. This will add object orientation, so you can rewrite and reorganize subsystems individually when adding new features. Or you can replace individual subsystems with freshly written Java.

Sometimes you can replace the components with ready-made software: we helped one very large insurance company that still had 2 meter lines of code in the inherited language that it created in the 1950s. We turned half of it into a legacy language compatible with Y2K, and replaced the second half with the modern payroll system that they bought from an external provider.

Answer 2

Obviously, we aimed to get the Java source code, which was very close to the source cobol, to facilitate the migration of people: they find a good old application that they wrote in cobol in the same structure.

One of our most important goals was to keep the initial developers on board: the way we did it. When the application is ported to Java, these people can begin to make it more OO as they further develop / reorganize.

If you don’t care about moving people, you can use a different strategy.

This 1-to-1 conversion also simplified and accelerated the 100% automatic conversion: a good consequence is that we made our recurring savings (3 million euros per year) much faster: we estimate 12-18 months. These early savings can be reinvested in OO refactoring

Feel free to contact me: [e-mail] or [e-mail]

Didier

Answer 3

My experience is similar, but a little different. We have a large and old code base in Ada (0.5Mloc for over 15+ years) that has recently been converted to Java. It was outsourced to a company that provided a combination of automatic / manual conversion. They also tested to make sure the Ada and Java systems behave the same.

Some parts of it written in Ada 95 (i.e. had OOP capability), but most of them were not

Now yes, the code does not comply with the same code standards written in Java, but we have been successfully using it since (18 months) without any serious problems. The main advantage we got was that we can now find more developers to support our code base with the skills to create supported code. (Anyone can develop in Ada, but, like any other language, if you have no experience in this, you can get an unreachable code)

Answer 4

In terms of risk avoidance, the NACA approach makes perfect sense. Reuse of their tools may not be. They used tool development to speed up their work in Java and Linux.

The result of NACA conversion will not be good enough, or even OO, and makes it difficult to hire new people. But it can be checked, it can be reorganized, and you can connect the best translators.

[edit] Ira, you do not seem to be very aware of the risk.

Submitting cobol programmers to a java course will not force them to write useful object-oriented code. It takes several years. During this time, their performance will be very low, and you can basically throw away all the code that they write in the first year. In addition, you will lose 10-20% of your programmers who are unwilling or unable to make the transition. Many people do not like to return to their initial status, and it will affect the hierarchical order, as some programmers choose a new language faster than others.

The NACA approach allows the business to continue to operate and does not exert unnecessary pressure on the organization. The conversion schedule is independent. Having a separate translator in java written by OO experts allows you to gradually use java for the old team. Writing test cases increases domain knowledge in the new java command.

The real GS system is a translator, and this is the place to connect the best translators. Make it easy and you don’t need to touch the generated code. If the generated code is ugly enough, this will happen automatically: :)

• older programmers will change cobol input;
• new java will change the translator.

[running translator once] is a bad strategy. Do not do this. And if you need to edit the generated code, display back. It can be automated. And it should be. It's much easier to do such things in a Smalltalk image, but you can do it with files. There are people with wide experience who support different views on the same artifact: chip designers come to mind.

The translator must be instrumental, so you can create daily calculations, for example.

• cobol input components;
• OO I / O components
• cobol style output components;
• OO style output elements.

You might want to read: Peter van den Hamer and Kees Lepoeter (1996) Design data management: five dimensions of CAD frameworks, configuration management and data management, IEEE materials, vol. 84, No. 1, January 1996.

[moving Cobol platforms] Migrating from Cobol on the mainframe to Cobol on Windows / Linux could be a viable strategy for the NACA team, but it was about switching to java. If the long-term goal is to have a modern OO system and get there with minimal operational risk, the NACA approach sounds. This is only one step. A lot of refactoring will follow.

Answer 5

I am surprised that no one mentioned the software reengineering toolkit for DMS. In the past, I watched COBOL conversion. Then I worked on "automatic programming." Before writing a translator, I looked for a bunch of previous efforts and products in this area. Semantic Designs-based GLAR was the best of the group.

That was many years ago. At that time, the tool translated COBOL into a modern language, reworked it, printed it, etc. Here is a link to it now.

http://www.semdesigns.com/Products/DMS/DMSToolkit.html

They are still around. They expanded the tool. This is more general. This can help people do automatic conversions or set up a conversion tool. It was designed to be extensible and customizable in the same way that Stephen pointed out. Thanks also to Cyrus for mentioning SoftwareMining. I will also study them if I encounter COBOL migration in the future.

Answer 6

I just looked at the NACA page and docs. From their documentation:

"Generated java uses Cobol type syntax, as close as possible to the original Cobol syntax, within, of course, the limits of the Java language. The generated code does not look like classic native Java and is not object oriented from the point of view of the application. This is an excellent choice to ensure smooth migration Cobol developers in the Java environment. The goal is to keep business knowledge in the hands of the people who wrote the original Cobol programs. "

I have not seen an example, but the quote gives a strong tint to the result. Its COBOL is encoded in Java.

You can always create a "translator" from one language to another simply by encoding the interpreter in the target langauge. This is IMHO absolutely terrible way to translate langauge when you finish with the worst of both worlds: you do not get the meanings of the new language, and you still need to know the old ones to keep the result alive. (No wonder this thing is called "Transcoder", I will never have heard this term before).

The argument for this trick is dropping mainframe costs. If the evidence that the cost of working on a convertible program is not a bog to save? I suspect it is true that people reduced their cost by dropping mainframes, and they didn’t care that the maintenance tasks became more expensive. Although this may be rational for guys to have operations, it is a stupid choice for the whole organization.

Heaven helps people who are victims of this tool.

EDIT May 2010: I found an example of NACA output; one of their testcases. This is absolutely gorgeous JOBOL. It’s good that they retain their COBOL programmers and do not want to hire any Java programmers. As you read this, make sure you remember this Java code.

/* * NacaRTTests - Naca Tests for NacaRT support. * * Copyright (c) 2005, 2006, 2007, 2008 Publicitas SA. * Licensed under GPL (GPL-LICENSE.txt) license. */ import idea.onlinePrgEnv.OnlineProgram; import nacaLib.varEx.*; public class TestLong extends OnlineProgram { DataSection WorkingStorage = declare.workingStorageSection(); Var W3 = declare.level(1).occurs(10).var(); Var V9Comp010 = declare.level(5).pic9(10).var(); Var V9Comp014V4 = declare.level(5).pic9(14, 4).var(); Var VX10 = declare.level(5).picX(10).var(); public void procedureDivision() { setAssertActive(true); move("9876543210", VX10); assertIfDifferent("9876543210", VX10); move(VX10, V9Comp010); long l = V9Comp010.getLong(); assertIfFalse(l == 9876543210L); multiply(1000, V9Comp010).to(V9Comp014V4); assertIfFalse(9876543210000L == V9Comp014V4.getLong()); String cs = V9Comp010.toString(); cs = V9Comp014V4.toString(); assertIfDifferent("9876543210000.0000", V9Comp014V4); inc(V9Comp010); assertIfFalse(9876543211L == V9Comp010.getLong()); CESM.returnTrans(); } 

Children: Only professionals do this. Do not try to do this at home.

Answer 7

You say reengineering . It’s good that many people all over the world are trying to do this. The bad news is that there are many problems associated with the reengineering of legacy applications: from missing sources to complex algorithms from compiler construction and graph theory fields.

The idea of ​​automatic translation is very popular until you try to convert something. Usually the result is terrible and unbearable. This is more indispensable than the original complex application. From my point of view, every tool that allows you to automatically translate from the old to the modern language is very marketing-oriented: it definitely says that people want to hear "translate your application from ... into Java once and forget it!", Than you buying a contract, and then you understand that you are very dependent on the tool (because you cannot without any changes in your application!).

An alternative approach is “understanding”: a tool that allows you to understand your legacy application in great detail. And you can use it for maintenance, or for documentation, or for rethinking on a new platform.

I know little about the history of Workbench modernization before Microfocus bought it last year and transferred development to another country. There were many comprehensive analysis tools and the number of target languages ​​supported (including Java). But not a single client used automatic code generation, so the development of part of the generation was frozen. As far as I know, PL / I support was mostly implemented, but it never ended. But you can still try, maybe this is what you are looking for.