NACA presented @ Jazoon 2009: mainframe/Cobol to Linux/Java migration

UPDATE: Project NACA has given birth to Eranea, a company dedicated to 100% automatic migration of mission-critical apps to Java & Linux. Check out www.eranea.com or email to contact@eranea.com for more information
________________________________________________________________________________

Pierre & I presented the NACA project at Jazoon 2009 in Zurich. It was another nice opportunity to present our automated solution to migrate (we say "transcode" within Publicitas) 100% automatically a Cobol application to its iso-functional Java equivalent.

As Jazoon is a major Java conference in Europe, we could go into very specific technical details in front of the most competent audience.

Pierre described the architecture of our "transcoding compiler" and exposed all of its advantages. Read the ending slides of this ppt very carefully if you want to get all details (... or get in touch with us !):

• many levels of cache to maximize performances of the new Java version of the old application. Through them, our Java-transcoded transactions and batches have better performances than their Cobol ancestors used to have on mainframe.
• pre-allocation of all program variable structures (COMMAREA of COBOL) to further improve performances but also to minimize garbage collection that freezes the system while running.
• strongly object-oriented architecture of resulting Java objects in order to maximize the effect of all controls done by compiler. As example, each old COBOL program becomes a Java class whose existence is checked at compile-time rather than at runtime. Very useful when your application is 4 millions lines of code like ours and when you want to track down every typing mistake in a continuous integration architecture like ours
• strong integration with Eclipse IDE for highest productivity for developpers: we even developed a plug-in to facilitate debugging and edition of old COBOL programs from Eclipse
• line-by-line equivalence between old COBOL programs and newly transcoded Java classes. The home developers don't get lost: they receive afterwards a Java application with the exact same structure as the original COBOL version
• support of IBM JVM as well as Sun JVM in order to also allow for the transcoding of stored procedures
• support of distinct character sets and encoding schemes (EBCDIC) between mainframe & Linux. Support of all resulting possibilities for data sorting.
• full management of multi-level COBOL data structures in Java independently of the UTF encoding (2 bytes per char) used by Java
• transparency of wrapping framework (raw JVM, Apache Tomcat, etc...) for the application
• etc...

We gave the URL of our open source (GPL licence) transcoding tools for participants. Please, give a chance to our tools if you enter such a migration project.

On my side, I emphasized the key aspects of such a project:

• economic motivation as core driver: move from a multi-million (CHF or euros) mainframe environment to an incredibly cheap and nimble farm of Linux Intel-based servers. The massive savings (3 millions euros / year in our case) allow for a quick auto-financing of the project far before its end. The main virtue of Open Source for a company like us remains clearly its very very low price.
• migrate people with technology: we believe that we succeeded in our project because we clearly demonstrated very early on to the people in place that they would find a new interesting job in the final constellation. That generated their full commitment to the project!
• iso-functionality as a must: migrating in such a manner prevents months of discussion about the final target. But, mostly, it allows for 100% automatic migration, a key factor for quality in the transcoding.
• no big-bang but numerous reversible steps: such a total migration with (tens of) thousands of new steps can never successfully reach the ends if you try big steps. Permanent incremental progress toward the goal is a much better approach. The nice consequences: small steps generate smaller local trouble when problems arise. Your users remain much more patient this way! Our experience was so...

Source: blog Media & Tech (par didier durand)