Code Search (Find, Follow), Analysis (Metrics, Static, Dynamic, Bugs) and Change (Modernization, Migration, Generation, Optimization, Rearchitecting)

A COBOL Migration you do NOT want

This example is not from a Semantic Designs' tool. It is taken from the NACA transcoder. which "translates" COBOL to Java, line-by-line, bit-for-bit, thus preserving exact functionality. The code sample was taken from one of NACA's publicly available test cases. It is, as the transcoder concept suggests, pretty much line for line with the COBOL (you can almost read the original COBOL; examine the W3 variable declaration below closely).

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();
  }
}

Pardon our public opinion, but this is a truly unmaintainable result.

The argument made by the original NACA team for this is that it "preserves the COBOL structure" so that the organizations' COBOL programmers can work with the translated code. If the company's COBOL programmers are so bad and so uninterested as to not be able to learn Java, then retaining them is a poor business decision. And the resulting code has the worst of both worlds: it may be legal Java, but it isn't idiomatic Java (consider declare.level(5).pic9(14, 4) ) and it isn't idomatic COBOL (consider multiply(1000,V9Comp101).to(V9Comp014V4) ). Showing this code to potential new hires with Java skills will surely drive them away. This loses the "maintainability improvement" and "ease of finding new staff" gains one hopes to gain with a migration; if these are not obtained, where are the real long term cost savings?

While we agree with intention of preserving application functionality during a migration (otherwise, how will you know the migration was successful?), we disagree with the NACA approach to achieve it.

Other Transcoders

The technical people behind NACA formed a company, Eranea to harness NACA in commercial contexts. Eranea claims to have "invested lots of man-years to reach something way better", so this tool is clearly no longer NACA. However, the result is still a "transcoder" (described that way by Eranea in the (uncopyrighted) slide presentation Automated Migration To Java). Eranea claims this improved technology is used successfully at a large Swiss bank. One of the slides show us this specific example, presumably of the improved technology:

(Double click on the image to see it with easily readable text)

This doesn't seem like an improvement, in our opinion, to any of the properties of NACA or transcoders in general. (Particulary odd is the goTo function in the Java code.)

An example Migration you might want can be found here.