Slide 2
CoJaC – COBOL to Java Converter

CoJaC ist unser Werkzeug zur Konver­tie­rung von histo­ri­schen COBOL-Appli­­ka­­ti­o­­nen in moderne Java-Lösun­­­gen. CoJaC generiert wartba­ren und perfor­man­ten Java-Code, welcher seman­tisch äquiva­lent zum COBOL-Code ist.
Das Werkzeug erreicht bei der Konver­tie­rung einen Automa­ti­sie­rungs­grad von bis zu 95 %. CoJaC verbin­det wissen­schaft­li­ches Know-how im Compi­ler­bau mit Kernkom­pe­tenz aus erfolg­rei­chen Migrationsprojekten.

CoJaC-TECHNO­­LO­­GIE

Für komplexe Überset­zungs­vor­gänge wird der Einsatz spezi­el­ler Konver­tie­rungs­werk­zeuge, sogenann­ter Trans­la­to­ren notwen­dig. Trans­la­to­ren arbei­ten in Analo­gie zu einem Compi­ler, der Quell­pro­gramme über verschie­dene Zwischen­stu­fen in ausführ­ba­ren Zielcode übersetzt.

CoJaC ist ein Trans­la­tor zur Konver­tie­rung von histo­ri­schen COBOL-Appli­­ka­­ti­o­­nen in moderne Java-Lösun­­­gen. Für die Belange der Sprach­kon­ver­tie­rung wurde dazu von uns das allge­meine Compi­­ler-Modell zum Trans­la­tor­mo­dell weiterentwickelt:

  • FRONT-END: Liest das COBOL-Programm einschließ­lich der dazuge­hö­ri­gen Copybooks ein und erzeugt daraus einen inter­nen Syntax­baum, der das vollstän­dige COBOL-Programm repräsentiert.
  • TRANS­FOR­MA­TOR: Überführt den COBOL-Synta­x­­baum in einen äquiva­len­ten Java-Synta­x­­baum. Die eigent­li­che Konver­tie­rung erfolgt auf der Basis von Syntax­bäu­men und nicht auf Basis von Quellcode.
  • POSTPRO­ZES­SOR: Zerteilt den komple­xen Java-Synta­x­­baum in einzelne Syntax­bäume, welche die Programm­struk­tur des zukünf­ti­gen Java-Program­­­mes repräsentieren.
  • GENERATOR/FORMATIERER: Generiert Java-Klassen und ‑Packa­ges aus einzel­nen Java-Synta­x­­bäu­­men und forma­tiert automa­tisch den Source­code laut Kundenvorgaben.
  • LAUFZEIT­SYS­TEM: Ermög­licht die Nutzung der COBOL-Daten­­ty­­pen und ‑Funktio­nen im konver­tier­ten Java-Code, welche in Java nicht 1:1 existieren.

FEATURES

  • Einbin­dung der Quell­text­kom­men­tare in den Zielcode
  • Struk­tu­rie­rung des Zielcodes in Java-Klassen und ‑Packa­ges durch unser Werkzeug JPackage nach Kundenvorgabe
  • Nutzer­spe­zi­fi­sche Forma­tie­rung des generier­ten Java-Codes
  • Unter­stüt­zung verschie­de­ner COBOL-Dialekte (IBM, HPE NonStop, BS2000)

MIGRA­TI­ONS­PFADE

Die nachfol­gende Tabelle zeigt beispiel­haft einige Migra­ti­ons­pfade der Basis­kom­po­nen­ten in das entspre­chende Migra­ti­ons­ziel auf:

MIGRA­TI­ONS­ASPEKTE

Die Migration geht weit über eine reine Programm­trans­for­ma­tion hinaus und beinhal­tet ebenso eine Architekturmigration:

Die Grafik skizziert beispiel­haft die Archi­tek­tur einer typischen COBOL-Appli­ka­tion und das daraus resul­tie­rende Java-Zielsystem.

  • COBOL-Server-Programme werden als Webser­vices im Java-Zielsys­tem bereitgestellt.
  • COBOL-Batch-Programme werden in autonome Java-Programme transformiert.

Das Laufzeit­sys­tem stellt in der Java-Zielum­ge­bung Klassen für die Abarbei­tung der migrier­ten Programme zur Verfü­gung. Dazu gehören Klassen für die COBOL-Daten­ty­pen (numeri­sche und alpha­nu­me­ri­sche Daten) und Basis­klas­sen für Arrays und Struk­tu­ren. Weiter­hin existie­ren Metho­den, welche die Funktio­na­li­tät von COBOL-Anwei­sun­gen imple­men­tie­ren, für die in Java keine nativen Anwei­sun­gen existie­ren (z.B. STRING und INSPECT). Weitere Bestand­teile sind stati­sche Metho­den zur Abbil­dung der Intrinsic Functions, Metho­den für die Typkon­ver­tie­rung und Klassen, welche die Funktio­na­li­tät der Schnitt­stel­len (Files, SQL, Middle­ware) bereit­stel­len. Das Laufzeit­sys­tem bildet die Grund­lage für einen kompak­ten, wartba­ren Java-Code.

Beispiele für die Anwen­dung des CoJaC-Laufzeitsystems:

Beispiel für die Migration von CALL-Statements

Beispiel für die Migration von CALL-Statements

Beispiel für die Migration von COMPUTE- und ADD-Statements

Beispiel für die Migration von COMPUTE- und ADD-Statements

Beispiel für die Migration von 88er Stufen

Beispiel für die Migration von 88er Stufen

COBOL-Server, die unter der Steue­rung einer Middle­ware (eines Trans­ak­ti­ons­mo­ni­tors) arbei­ten, werden von CoJaC in Java-Webser­vices übersetzt und in einen Appli­ca­tion Server integriert. Dabei werden Middle­ware-spezi­fi­sche Daten und Anwei­sun­gen entfernt bzw. durch entspre­chende Webser­vice-Funktio­na­li­tät ersetzt. Die Schnitt­stelle ändert sich dabei inhalt­lich nicht. Die Webser­vices verar­bei­ten die gleichen Messages wie vorher die COBOL-Server. Notwen­dige Konver­tie­run­gen kapselt das Laufzeit­sys­tem, welches auch die Verwal­tung der Trans­ak­tio­nen übernimmt. Unser Werkzeug MidaS (Middle­ware as a Service) ist eine schlanke Alter­na­tive zu kommer­zi­el­len Syste­men. MidaS stellt ein genau auf die migrier­ten Online-Programme zugeschnit­te­nes Inter­face bereit und ist leicht in eine Java-Server­land­schaft integrierbar.

Beispiel für die Middleware-Migration:

Beispiel für die Migration eines die Middleware nutzenden COBOL-Servers in einen Webservice

Beispiel für die Migration eines die Middle­ware nutzen­den COBOL-Servers in einen Webservice

Die in COBOL verwen­de­ten Daten­files werden bei der Migration mit unserem Werkzeug FiRe in relatio­nale Daten­bank­ta­bel­len umgesetzt. Dabei werden die verschie­de­nen Organi­sa­ti­ons­for­men und Zugriffs­me­tho­den berück­sich­tigt. In den konver­tier­ten Java-Program­men wird unter Nutzung von Metho­den, welche das Laufzeit­sys­tem bereit­stellt, auf die Daten­bank­ta­bel­len zugegrif­fen. Die Laufzeit­me­tho­den emulie­ren die origi­na­len COBOL-Anwei­sun­gen zur File-Arbeit (OPEN, READ, READ NEXT, CLOSE, …).

Beispiele für die File-Migration:

Beispiel für die Migration der File-Definition und -Satzstruktur

Beispiel für die Migration der File-Defini­tion und ‑Satzstruk­tur

Beispiel für die Migration der File-Zugriffe

Beispiel für die Migration der File-Zugriffe

Stati­sche SQL-Anwei­sun­gen, die in den COBOL-Quell­text einge­bet­tet sind, werden von CoJaC in dynami­sche SQL-Anwei­sun­gen konver­tiert. In das Java-Laufzeit­sys­tem wurden Metho­den zur Verwal­tung der Daten­bank­ver­bin­dung, zum Daten­bank­zu­griff, zum Lesen und Schrei­ben von Daten in die Hostva­ria­blen sowie zur Fehler­be­hand­lung integriert, welche die im Basis­sys­tem vorhan­dene Funktio­na­li­tät abbil­den. Mit dem Übergang zu dynami­schem SQL sind erfah­rungs­ge­mäß keine Laufzeit­nach­teile verbun­den. Gleich­zei­tig wird die flexi­ble Erstel­lung und Änderung von SQL-Anwei­sun­gen ermöglicht.

Beispiele für die Migration von Embed­ded SQL:

Beispiel für die Migration eines SELECT-Statements mit Eingabe- und Ausgabe-Hostvariablen

Beispiel für die Migration eines SELECT-State­ments mit Eingabe- und Ausgabe-Hostvariablen

Beispiel für die Migration eines INSERT-Statements

Beispiel für die Migration eines INSERT-Statements

Beispiel für die Migration von Cursor-Handling-Statements

Beispiel für die Migration von Cursor-Handling-Statements

Die Migration der ASCII-Masken in Webober­flä­chen erfolgt mit unserem Werkzeug MaTriX. In MaTriX integriert ist ein sogenann­ter Masken­ser­ver, der den Infor­ma­ti­ons­aus­tausch zwischen den Masken und den Webser­vices über Messages koordiniert.

FAQ ZUR SPRACHMIGRATION

Wir haben in mehre­ren Migra­ti­ons­pro­jek­ten bewie­sen, dass das funktio­niert (z.B. COBOL nach Java bei ITZBund und SüdLea­sing). Bei COBOL nach Java können derzeit große Teile des COBOL-Codes (ca. 90–95%) automa­tisch konver­tiert werden. Das Werkzeug CoJaC erzeugt dabei seman­tisch äquiva­len­ten Java-Code. Die restli­chen 5–10% werden z.B. durch geeig­nete Kommen­tare deutlich ausge­wie­sen, was eine manuelle Konver­tie­rung erleichtert.

Die COBOL-Programme wurden in einer proze­du­ra­len Sprache imple­men­tiert. Eine Neuauf­tei­lung der Funktio­na­li­tät auf einzelne Klassen und Metho­den im Sinne des objekt­ori­en­tier­ten Entwurfs ist automa­ti­siert nicht möglich. Das ist auch nicht unbedingt wünschens­wert, schließ­lich müssen die Entwick­ler den Code auch wieder­erken­nen. Eine zukünf­tige, objekt­ori­en­tierte Weiter­ent­wick­lung der generier­ten Java-Appli­ka­tion kann natür­lich erfolgen.

Ja, defini­tiv. Der Grund­auf­bau des generier­ten Java-Codes ist analog zum COBOL-Code. Dadurch steigt der Wieder­erken­nungs­ef­fekt. Auch Kommen­tare werden an die korrek­ten Stellen des Zielcodes einge­fügt. Die Entwick­ler des Altsys­tems finden sich (Java-Kennt­nisse voraus­ge­setzt) schnell zurecht. Es gibt ausrei­chend Referenz­pro­jekte für die automa­ti­sche Sprach­trans­for­ma­tion von COBOL nach Java, die praktisch bewei­sen, dass der generierte Code wartbar und perfor­mant ist. Die für Java verfüg­ba­ren, moder­nen IDEs (z.B. Intel­liJ und Eclipse) erlau­ben dann eine komfor­ta­ble Weiterentwicklung.

Beden­ken werden oft von Mitbe­wer­ben geäußert, welche eigene COBOL-Entwick­lungs­um­ge­bun­gen vermark­ten und deshalb kein Inter­esse zeigen, “von COBOL weg” zu migrieren.

Nicht vollstän­dig konver­tier­bar sind solche Anwei­sun­gen, für die Java nicht die entspre­chen­den sprach­li­chen Mittel zur Verfü­gung stellt. Das betrifft vor allem die sogenann­ten “compi­ler-direc­ting state­ments”. Diese werden erst bei der Überset­zung des COBOL-Program­mes ausge­führt, sozusa­gen in einer Präpro­zes­sor-Phase. Java stellt aber keinen Präpro­zes­sor zur Verfü­gung. Somit sind diese Anwei­sun­gen nicht mit den üblichen Mecha­nis­men konver­tier­bar. Das bedeu­tet jedoch nicht, dass z.B. keine Copybooks konver­tiert werden können. CoJaC beinhal­tet einen ausge­klü­gel­ten Mecha­nis­mus zur Konver­tie­rung von Copybooks in separate Java-Klassen.

GO TO-Anwei­sun­gen sind komplett automa­ti­siert migrier­bar. Dabei wird zunächst versucht, sie durch Java-typische Anwei­sun­gen zu erset­zen. Sprünge an das Ende einer Section werden z.B. durch eine return-Anwei­sung in Java übersetzt. Ist das nicht möglich, übernimmt das CoJaC-Laufzeit­sys­tem die Ablauf­steue­rung. Im Programm wird dann das GO TO durch den Aufruf einer skip()-Methode reali­siert.
Die Abbil­dungs­vor­schrif­ten von COBOL-Konstruk­ten in Java-Konstrukte wurden bewusst so gewählt, dass der entste­hende Java-Code Java-typisch ist. Es werden z.B. für die verschie­de­nen Daten­ty­pen Java-Klassen in einem Laufzeit­sys­tem zur Verfü­gung gestellt, die alle notwen­di­gen Infor­ma­tio­nen, wie Länge etc., kapseln und Metho­den zu deren Verwal­tung anbie­ten. Wo es möglich ist, werden direkt die nativen Java-Anwei­sun­gen verwen­det, z.B. für Schlei­fen (while, for) oder if-Anwei­sun­gen.
Die prinzi­pi­elle Struk­tur eines Program­mes bleibt identisch. Aus einem Programm wird eine Klasse, aus Daten­struk­tu­ren die (priva­ten) Daten­fel­der dieser Klasse und aus einzel­nen Sections der PROCEDURE DIVISION werden die Klassen-Metho­den. Dabei bleibt die Reihen­folge im Quell­text bestehen. 

Copybooks werden in separate Klassen konver­tiert. Auch bei mehrfa­cher Verwen­dung dieser Copybooks entsteht dabei nur eine Klasse. Klone entste­hen ledig­lich bei Verwen­dung von COPY mit REPLACING-Klausel oder bei COPY in der PROCEDURE DIVISION. Wir verfü­gen mit JPackage über ein Werkzeug, mit dem so entstan­dene Klone wieder zusam­men­ge­führt werden können.

Neben den dabei anfal­len­den, wesent­lich höheren Kosten sollten Sie bei dieser Entschei­dung auch die Projekt­dauer beach­ten. Wenn über 90% des Java-Codes automa­tisch generiert werden, ist ein Programm natür­lich schnel­ler umgesetzt als von Hand. “Code freezes” und eventu­elle Sperr­zei­ten bei der Weiterentwicklung/Wartung des Program­mes werden damit minimiert. Unsere Erfah­run­gen besagen, dass sich eine Software-Migration zu einer Neuent­wick­lung im Verhält­nis von 1:8 verhält, d.h., wenn Sie 5 Perso­nen­jahre für ein Migra­ti­ons­pro­jekt unter Nutzung von Trans­for­ma­ti­ons­werk­zeu­gen veran­schla­gen, dann benöti­gen Sie für eine Neuent­wick­lung ein- und dessel­ben Programm­sys­tems 40 Personenjahre.

Für eine Neuent­wick­lung existie­ren zwei alter­na­tive Ansätze: Entwe­der, Sie schrei­ben das origi­nale Programm 1:1 in Java um. Dann wird der Code dem automa­tisch migrier­ten Code ähnlich sein, so dass Sie auch automa­tisch migrie­ren können. Oder Sie extra­hie­ren die Business-Logik des Program­mes, erstel­len daraus eine Spezi­fi­ka­tion und entwi­ckeln dann das Programm neu. Die Extrak­tion der Business-Logik ist jedoch ein sehr aufwen­di­ger und fehler­an­fäl­li­ger Prozess.

Natür­lich. Das ist ein weite­rer Vorteil der Software-Migration. Die Entwick­ler, welche die konver­tier­ten Programme zukünf­tig warten, müssen kein COBOL kennen. Eine Einar­bei­tung kann allein anhand des Java-Codes erfolgen.

Nun, Java müssen sie natür­lich lernen. Daran führt kein Weg vorbei. Dafür haben diese Program­mie­rer aber den Vorteil, dass sie sich bereits mit dem fachli­chen Hinter­grund der Programme ausken­nen, wogegen sich Neuein­stei­ger diesen natür­lich erst aneig­nen müssen.

Auch das ist ein Argument, welches häufig von Kunden geäußert wird, welches sich in bishe­ri­gen Projek­ten aber nie bestä­tigt hat. Perfor­mance-Probleme existier­ten dort nur lokal begrenzt auf einzelne Programme und konnten durch geeig­nete Optimie­rungs­maß­nah­men besei­tigt werden. Heutige JVM arbei­ten dank der fortge­schrit­te­nen Techno­lo­gie der “just-in-time-Compi­ler” die Java-Programme nur wenig langsa­mer ab als der Prozes­sor die kompi­lier­ten COBOL-Programme.

Werkzeuge für die Software-Migration erfor­dern einen großen Entwick­lungs­auf­wand. Zusätz­lich benötigt man ein ganz spezi­el­les Infor­ma­tik-Know-how (Compi­ler­tech­nik). Wir besit­zen mehr als 25 Jahre Erfah­rung in der Entwick­lung von Werkzeu­gen für die Software-Migration. Die Basis bilden Forschungs­ar­bei­ten auf dem Gebiet der Compi­ler­tech­nik an der Fakul­tät für Infor­ma­tik der TU Chemnitz. Wir betrei­ben weiter­hin Forschung und Entwick­lung in Zusam­men­ar­beit mit den Univer­si­tä­ten Koblenz-Landau und Olden­burg. Die Ergeb­nisse spiegeln sich direkt in unseren Techno­lo­gien und Werkzeu­gen wider.

Im Verlauf der letzten Jahre entstan­den dabei verschie­denste Parser, Code-Genera­to­ren, Forma­tie­rungs- und Metawerk­zeuge, die alle in unserer pecBOX (pro et con – Toolbox für die Software-Migration) zusam­men­ge­fasst sind und die in unseren Migra­ti­ons­pro­jek­ten zum Einsatz kommen. Kein Migra­ti­ons­pro­jekt gleicht dem anderen. Bei neuen Projek­ten werden notwen­dige, neue Migra­ti­ons­werk­zeuge aus den in der pecBOX befind­li­chen Kompo­nen­ten zusam­men­ge­stellt, wodurch sich deren Entwick­lungs­zeit verkürzt. Durch diesen generi­schen Ansatz werden Migra­ti­ons­pro­jekte preis­wer­ter und die Projekt­lauf­zeit verkürzt sich. Das bestä­ti­gen zahlrei­che Referenz­kun­den (Amadeus Germany GmbH, MAN Truck & Bus SE, ITZBund, SüdLea­sing GmbH, …).

DOWNLOADS

“Vom COBOL-Server zum Java-Webser­vice“
Abstract zum 12. Workshop “Software-Reengi­nee­ring” am 03.–05. Mai 2010 in Bad Honnef, erschie­nen in:
Software­tech­nik-Trends, Band 30, Heft 2, Mai 2010

“Ein Trans­la­tor für die COBOL-Java-Migration“
Abstract zum 13. Workshop “Software-Reengi­nee­ring” am 02.–04. Mai 2011 in Bad Honnef, erschie­nen in:
Software­tech­nik-Trends, Band 31, Heft 2, Mai 2011

Success Story: “Erfolg­rei­che BS2000-Migration bei ITZBund”

ZUM DOWNLOAD­BE­REICH