We have proved in several migration projects that this works (e.g. COBOL to Java at ITZBund and SüdLea­sing). For COBOL to Java, large parts of the COBOL code (95–99 %) can be conver­ted automa­ti­cally. The CoJaC tool genera­tes seman­ti­cally equiva­lent Java code. The remai­ning 1–5 % are clearly indica­ted, for example, by appro­priate comments facili­ta­ting the manual conversion.

The COBOL programs were imple­men­ted in a proce­du­ral language. A redis­tri­bu­tion of function­a­lity into indivi­dual classes and methods in the sense of the object-orien­ted concept is not automa­ti­cally possi­ble. This is not neces­s­a­rily desira­ble since the develo­pers must recog­nise the code. A future, object-orien­ted further develo­p­ment of the genera­ted Java appli­ca­ti­ons can, of course, be done.

Yes, defini­tely. The basic struc­ture of the genera­ted Java code is analog­ous to the COBOL code. This increa­ses the recogni­tion effect. In addition, comments are inser­ted at the right positi­ons of the target code. The develo­pers of the old system (Java knowledge being the prere­qui­site) will find their way quickly. There are enough reference projects for automa­tic language trans­for­ma­tion from COBOL to Java, which practi­cally prove that the genera­ted code is maintainable and perfor­mant. The available, modern IDEs (e.g. Intel­liJ and Eclipse) then allow a comfor­ta­ble further development.

Concerns are often expres­sed by compe­ti­tors who market their own COBOL develo­p­ment environ­ments and are, there­fore, not interes­ted in migra­ting “away from COBOL”.

Those state­ments, for which Java does not provide the corre­spon­ding language resour­ces, are not comple­tely conver­ti­ble. This mainly concerns the so-called “compi­ler-direc­ting state­ments”. These are first imple­men­ted during the trans­la­tion of the COBOL program so to say in a prepro­ces­sor step. Java, however, does not provide a prepro­ces­sor. Thus, these state­ments cannot be conver­ted with the common mecha­nisms. CoJaC includes a sophisti­ca­ted mecha­nism to convert copybooks into separate Java classes.

The state­ments for model­ling COBOL constructs into Java constructs were delibera­tely chosen in such a way that the genera­ted code is typical for Java. For example, Java classes encap­su­la­ting all neces­sary infor­ma­tion, such as length etc., and offering methods to adminis­trate them are provi­ded for diffe­rent data types in a runtime system. Where possi­ble, the native Java state­ments are directly used for loops (while, for) or if statements.

Copybooks are conver­ted into separate classes. Even if these copybooks are used several times, only one class will be created. Clones are only created when using COPY with REPLACING clause or COPY in the PROCEDURE DIVISION. We have with JPackage a tool capable of reuni­ting the resul­tant clones.

In addition to the signi­fi­cantly higher costs, you should also consider the project duration in this decis­ion. If more than 95 % of the Java code is genera­ted automa­ti­cally, the program is of course conver­ted more rapidly than manually. Code freezes and poten­tial blocking times during further development/program mainten­ance will thus be minimi­sed. Our experi­ence has shown that the software migration in relation to a new develo­p­ment lies at 1:8, which means that if you calcu­late 5 man-years for a migration project using trans­for­ma­tion tools, you will need 40 man-years for a redeve­lo­p­ment of the same program system.

There are two alter­na­tive approa­ches for a redeve­lo­p­ment: either you rewrite the origi­nal program 1:1 in Java, in which case the code will be similar to the automa­ti­cally migra­ted code, and you can also automa­ti­cally migrate; or you extract the business logic of the program, create a speci­fi­ca­tion and then develop the program anew. The extra­c­tion of the business logic is however a very time-consum­ing and error-prone process.

Of course, yes. This is another advan­tage of software migration. The develo­pers maintai­ning the conver­ted programs in future do not have to know COBOL. They can familia­rise themsel­ves with the environ­ment solely on the basis of the Java code.

Well, they have to learn Java. There is no way around this. These programm­ers, however, have the advan­tage that they are already familiar with the techni­cal background of the programs, whereas newco­mers have, of course, to first acquire the skills.

This is also an argument frequently voiced by custo­mers but that has never been found to be true in earlier projects. Perfor­mance problems only occur limited to indivi­dual programs and could be elimi­na­ted by suita­ble optimi­sa­tion measu­res. Thanks to the advan­ced technology of the “just-in-time-Compi­ler”, today’s JVM process Java programs only slightly slower than the proces­sor the compi­led COBOL programs.

Tools for software migration require exten­sive develo­p­ment effort. In addition, very speci­fic know-how in infor­ma­tics (compi­ler technology) is neces­sary. We have 30 years of experi­ence in the develo­p­ment of tools for software migration. The basis is in its years of research work in the field of compi­ler technology at the Faculty for Infor­ma­tics at the TU Chemnitz. We still carry out research and develo­p­ment in coope­ra­tion with the univer­si­ties of Koblenz-Landau and Olden­burg. The results are directly reflec­ted in our techno­lo­gies and tools.

In the course of past years, diffe­rent types of parser, code genera­tors, format­ting and meta tools have been develo­ped which are all combi­ned in our pecBOX (pro et con – Toolbox for Software Migration) and used in our migration projects. No migration project is like the other. For new projects, neces­sary, new migration tools are compi­led from the pecBOX compon­ents thus reducing the develo­p­ment time. This generic approach makes migration projects less expen­sive and reduces the project duration. This has been affirmed by numerous reference custo­mers like Amadeus Germany GmbH, MAN Truck & Bus SE, ITZBund, SüdLea­sing GmbH, to name a few.