Als Mrs. Grace Murray Hopper, die in den fünfziger Jahren Konteradmiral der US Navy war, mit den Vorarbeiten zur Entwicklung einer neuen Programmiersprache zur Lösung von Verwaltungsaufgaben bei der amerikanischen Marine beauftragt wurde, hat sie nicht im Traum daran gedacht, dass sie den Grundstein für die erfolgreichste Programmiersprache der Computerindustrie legen würde. Zusammen mit Vertretern von IBM, der amerikanischen Regierung und der Geschäftswelt wurde unter der Leitung des National Bureau of Standards eine gemeinsame Programmiersprache für Handel, Banken, Versicherungen und Verwaltung entwickelt. Diese „COmmon Business Oriented Language“, kurz Cobol genannt, wurde erstmals im Jahr 1960 in Amerika vorgestellt. Der Tod von Cobol wurde in den 1990er, den für Client/Server-Lösungen euphorischen Jahren übertrieben publiziert und hervorgehoben.

Nun ist aber das Gegenteil eingetreten: Cobol wird nach 42 Jahren täglich jünger. Laut Gartner Inc. werden weltweit 80 Prozent aller Business-Applikationen in Cobol ausgeführt. Das entspricht ca. 10 Milliarden Zeilen Code im täglichen Einsatz, mehr als 5 Millionen Zeilen werden jährlich neu geschrieben. Das Aufkommen von Distributed Computing und Client/Server-Lösungen hat das Erscheinungsbild in der Rechnerwelt nachhaltig und für immer verändert. Das Konzept benutzerfreundlicher Schnittstellen sowie durch den Anwender zu gestaltender Benutzeroberflächen will keiner widerrufen. Die Zeiten der „Green Screens“ gehören auch für Cobol endgültig der Vergangenheit an.

Um die Migration einer bestehenden Cobol-Anwendung auf eine Client/Server-Architektur als Web-Service oder als e-Business-Applikation durchzuführen, stehen heute Java-fähige Cobol-Compiler zur Verfügung.

Betrachtungsweise zu Java-fähigem Cobol

Die verschiedenen Hersteller bieten dazu unterschiedliche Ansätze an. Alle haben das gleiche Ziel: Dem Entwickler eine möglichst einfache Lösung anzubieten. Je nach Klassifizierung unterscheiden sich dabei im Wesentlichen nur drei oder vier Methoden.

Wie sieht die bisherige Praxis aus?

Da ist die Einbindung einer PC-Emulation, das bedeutet: „Green Screens“ innerhalb eines Benutzer-Browsers. Damit wird eine aufwendige Client-Installation vermieden und Unternehmen können die Distribution zentralisieren. Diese Methode lässt sich etwa so beschreiben: Es handelt sich nach wie vor um ein „Screen Scraping“, nur mit dem Unterschied, dass es statt Windows mit einem Browser ausgeführt wird. Phil Murphy, Direktor der Giga Group Inc. aus Cambridge, Mass., nannte diese Lösung einmal „GUI on the fly“.

Wenn eine solche Lösung nicht ausreicht oder Unternehmen die Benutzerschnittstelle ausführlicher kontrollieren wollen, werden in der Regel Screen-Scrapping-Tools eingesetzt. Diese bieten eine umfangreichere Schnittstelle und erlauben dem Entwickler, Radio-Buttons einzufügen und Eigenschaften – wie die Navigation – durch eine Anzahl von Screens zu erreichen. Dahinter steht eine „Many-to-one-“ oder „One-to-many“-Element-Kombination von verschiedenen Screens in einem einzelnen Browser.

Die nächste Ebene könnte man als Komponentialisierung einer Cobol-Anwendung bezeichnen. Dabei wird ein Teil des Screens genommen und als eine Art Komponente gepackt – EJB, COM usw. – und ihm die Fähigkeit zum Aufruf gegeben. Als Verbesserung aus diesem Prozess ergibt sich die Behandlung jeder Komponente als einzelnes Objekt. Vorausgesetzt wird dabei, dass die unterschiedlichen Komponenten einer Anwendung neu eingebunden werden und man sich später auch von einigen trennen kann. Wenn jede Komponente zu einem Objekt wird, muss die Anwendung notwendigerweise auch auf andere Verweise umadressiert werden, sobald eine Komponente entfernt wird. Solche Werkzeuge sind nur dann sinnvoll, wenn als erklärtes Ziel die spätere Migration auf andere Plattformen geplant ist. Viele dieser Anwendungen haben eine 3-Tier-Architektur und beinhalten Lastverteilung und Failover. Manche arbeiten als virtuelle Server, so dass sich die Server-Komponente auf der Host-Maschine befindet und daher höher skalierbar ist als z.B. ein oder auch mehrere NT-Systeme zusammen.
Eine Anmerkung dazu: Bei dieser Vorgehensweise, bei der Software-Entwickler den Cobol-Code bearbeiten und gleichzeitig eine Hilfssoftware benutzen, die Business-Regeln identifiziert, bedeutet jeder Eingriff eine Verletzung der abhängigen Logik dieser Business-Regeln. Mit Einbindung des neuen Codes geht das weit über eine Re-Compilierung hinaus.

Dale Vecchio, Research Direktor der Gartner Inc. in Stamford, Conn., unterscheidet zwischen drei weiteren Methoden: Erstens, die Software-Entwicklung steht im Mittelpunkt, zweitens, der Einsatz eines Adapters oder Connectors wird bevorzugt oder drittens, man
setzt XML ein.

Wo die Programmentwicklung im Mittelpunkt steht, wird direkte Java-nach-Cobol-Programmierung verlangt, um eine Verbindung oder Übersetzung zu erreichen. Das wirft jedoch daraus resultierende Probleme auf. Wer mit Mainframe Cobol arbeitet und plant, die Entwicklung auf dem Mainframe durchzuführen, wird mit erheblichen Sprachproblemen konfrontiert. Cobol kann von Java nicht aufgerufen werden und man muss mit entsprechenden Hilfsmitteln arbeiten.

Die Vorgehensweise mit Adapter/Connector-Lösungen lässt den Programmierer neue Programme in einer Java-Integrierten Entwicklungsumgebung (IDEs) oder mittels MS Visual Basic entwickeln. Er kann auf einen integrierten Calling-Mechanismus zurückgreifen, der Informationen vom Legacy-System extrahiert. Dabei bleibt der Legacy-Code voll intakt. Diese Methode kann benutzt werden, wenn die Anwendung für eine bestimmte Systemschnittstelle entwickelt wurde. Sie wird oft für eine CICS-Transaktionsentwicklung unter Einsatz von einfachen Terminals eingesetzt. Ein Vorteil des Adapter/Connector Approches: Er ist mühelos und unkompliziert zu realisieren, speziell bei der Entwicklung interaktiver Systeme. Aber wie auch immer, zum Ergebnis einer Adapter/Connector- und Screen-Scraper-Lösung gehören Probleme mit Performance und Zuverlässigkeit – die Verbindungen sind störanfällig und das System sollte über einen guten Error-Recovery-Mechanismus verfügen. Diese Anfälligkeit macht die Dinge dann noch wesentlich schwieriger, wenn die Daten aus verschiedenen Legacy-Quellen stammen.

Beim dritten Ansatz, XML als Verbindungsglied zu nutzen, werden XML-Meldungen außerhalb des Mainframes generiert. Diese Methode wird durch die Verbreitung von Web-Services bald der Vergangenheit angehören und damit auch von der Bildfläche verschwinden.

Bei den vorgenannten Tools ist eine GUI-Anpassung nur auf Microsoft Windows Systemen möglich, nicht jedoch auf Unix, Linux oder anderen Plattformen.

Die Mitbewerber mit einer neuen Cobol-Technologie

LegacyJ Corp., San Jose, Kalifornien, hat eine patentierte Methode, um Cobol-Code für die Java Virtuelle Maschine (JVM) zu kompilieren. Der existierende Code wird ohne Änderung kompiliert. Im Gegensatz zur Konvertierung und Migration der Daten entstehen dabei keine größeren Kosten für eine Implementierung. Bei dieser Methode entstehen in der Regel nur die Kosten für die Re-Kompilierung und die anschließenden Testarbeiten.

Ein Beispiel ist der Kunde „Walker Interactive Systems Inc.“, ein Anbieter für e-Business-Lösungen in San Francisco. Dieses Unternehmen wollte eine Mainframe-basierende Finanzanwendung für den plattformunabhängigen Einsatz überarbeiten und dabei EJBs zum Einsatz bringen. Die gesamte Applikation umfasste ca. 2 Millionen Zeilen Code und bestand aus mehr als 1.000 Modulen. Durch den Einsatz des LegacyJ-Tools war der komplette Code nach ca. einem Monat neu kompiliert. Anschließend war es nur noch eine Angelegenheit des Testens, um sicherzustellen, dass der Code auch das ausführte, wozu er entwickelt wurde.

LegacyJ führendes Tool ist PERCobol, ein Cobol-Compiler für den Einsatz kritischer Geschäftsanwendungen. Das Tool entspricht voll dem ANSI 1985 X3.23b-Standard und unterstützt die Nachträge zum Cobol-Standard. Darüber hinaus werden bekannte und populäre Cobol-Erweiterungen inklusive IBM S/390 Cobol, OS/400 ILE Cobol, HP Cobol II/XL, WANG Cobol, MicroFocus, AcuCobol; X/Open und der überwiegende Teil des neuen Cobol-2002-Standards unterstützt. Das Produkt kann mit bestehenden Cobol-Anwendungen integriert werden oder es kann unabhängig von beliebigen Cobol-Compilern oder Runtimes ausgeführt werden. Es ist 64-bit-fähig, objektorientiert, multithreaded und grafisch, so dass es auch grafische Screens erstellen kann.

Das Tool ermöglicht dem Software-Entwickler, Cobol-Programme ohne oder mit nur geringen Änderungen zu kompilieren, um diese auf einer Java-virtuellen Maschine auszuführen. Cobol-Code und Business-Logik werden übernommen und in Java-Applikationen, Servlets, Applets oder Java Beans kompiliert. Einige neue Fähigkeiten erfordern dabei zusätzliche programmatische Erweiterungen, während andere automatisch generiert und durch die PERCobol Runtime Libraries voll unterstützt werden. PERCobol unterstützt MQSeries, CICS Clients, Network File System (NFS), Secure Socket Layer (SSL) und XML, wie sie neben anderen Funktionen für Enterprise und Distributed Computing vorausgesetzt werden.

Obwohl PERCobol vieles erleichtert, bleibt doch noch einiges zu tun. „Es ist kein Magic-Tool, sofern ein paar Tausend Module neu kompiliert werden sollen, aber dieser Prozess muss durchgeführt werden“, meint dazu Chuck Townsend, Präsident der LegacyJ Corp.

Bei Micro Focus International, Rockville, MD., sieht es Ian Archbell, Direktor für Produkt-Entwicklung, ähnlich. Nach seiner Aussage ist ein Java-fähiger Cobol-Code zwar nicht alles um Java herum. Dafür werden aber Entwicklungskosten minimiert, um in einer Legacy-Umgebung die Möglichkeit webfähiger Legacy-Applikationen ohne Code-Änderung auf dem Host zu realisieren. Die Steigerung der Fähigkeiten einer strategischen Anwendung und die Beeinflussung von Java in einem neuen technologischen Umfeld – speziell für Applikation-Server und Netscape iPlanet, BEA Weblogic und IBM WebSphere – tragen ebenfalls zu einer enormen Kostensenkung bei.

Dazu bietet Micro Focus die Produkte „Net Express“ und „Server Express“ an. Ersteres ist ein Produkt für die Windows-Plattform und ermöglicht Unternehmen, Cobol-Anwendungen automatisch als Enterprise JavaBeans oder als COM-Objekte zu „verpacken“. Letzteres ist eine IDE zur Kreation von Cobol-Applikationen für das Unix-Umfeld. Die letzte Version von Server Express ist v2.0.1.1 und ermöglicht dem Anwender die Ausführung neuer, in Cobol entwickelter Web-Applikationen unter Benutzung von Wizards im Micro Focus Net Express. Die Ausführung mit einer GUI-Oberfläche ist aber nur auf einem Microsoft Windows-Client möglich.

Darüber hinaus bietet das Unternehmen den Enterprise Link-Generator an. Dieser Generator lässt den Benutzer CICS-Transaktionen in EJBs übertragen, jeweils eine zur Zeit oder auch verschiedene zusammen. Ein Beispiel: Eine Update-Funktion besteht aus drei separaten CICS-Transaktionen. Der Link Generator überlässt dem Entwickler die Entscheidung zu einer automatischen Selektion von diesen Transaktionen und generiert eine neu zusammengesetzte Applikation mit einer neuen CICS-Transaktion auf dem Mainframe, welche die existierenden Transaktionen zusammenfasst, aber sonst unverändert bleibt.

Der Link-Generator generiert auf dem Mainframe auch Verknüpfungen zu MQSeries und falls das Benutzer-System einen „Middle Tier“ zulässt, generiert es EJBs auf diesem Tier sowie einer JavaServer Page, welche wiederum mit MQSeries verknüpft ist. Cobol-Entwickler, die diese Vorgehensweise wählen, benötigen ebenso wie bei den LegacyJ-Produkten keine Java-Kenntnisse. Werden die so erzeugten EJBs der Palette von EJBs in einer Java-Entwicklungsumgebung beigefügt, benötigt der Programmierer auch keine Kenntnisse über das Mainframe-Umfeld. Das ist vielleicht bedeutsam, weil der Kreis der Cobol-Entwickler in der Regel zwar schon eine Menge grauer Haare hat, dafür aber auch umfangreiche Business-Kenntnisse besitzt. Java-Entwickler dagegen haben eine Menge technisches Wissen, aber in vielen Fällen fehlt ihnen das massive Verständnis von Geschäftsabläufen.

Mit seinem Transidiom Tool packt Seagull Software Inc., Atlanta, Java um Cobol herum. Transidiom lässt Cobol-Entwickler XML-, Java- und COM-Schnittstellen automatisch generieren, indem es Mainframe und 5250-Business-Funktionen in Komponenten mit aufrufbaren XML-, Java- und/oder COM-Schnittstellen übersetzt. Diese lassen sich dann einfach in neue Anwendungen integrieren. Damit können Cobol-Programmierer Aufgaben oder Geschäftsprozesse erfassen, die Schnittstelle generieren und das Ergebnis an Java-Entwickler weitergeben. Diese sind damit in der Lage, schnell eine Java-Applikation zu erstellen, da sie auf ein Set von JavaBeans zurückgreifen können, das jede Art von Business-Funktionen enthält. Den Haan von Seagull Software meint dazu, dass diese Technik sich als sehr effizient und erfolgreich heraus gestellt hat. Die Java-Verpackung dient dabei als Abfederung bzw. als Puffer Layer, wenn Wartung am Back-End Cobol-Code durchgeführt wird. Solange das externe Interface unverändert bleibt, müssen auch keine Änderungen an der Front-End-Anwendung durchgeführt werden.

Wie kann existierender Cobol-Code auf heutige Bedürfnisse angepasst werden?

Wenn man die Vorgehensweise vom Standpunkt der Fähigkeiten einer bestehenden Cobol-Anwendung betrachtet, wird man feststellen, dass Java-Entwickler wohl „etwas“ entwickeln können, was aber nicht unbedingt den Geschäftsabläufen entspricht.

Alles neu zu erstellen, bedeutet eine Menge Arbeit und noch weit mehr Kosten. Dagegen ist es relativ unkompliziert, herauszufinden, welcher Ansatz zu Java-fähigem Cobol-Code für ein Unternehmen am besten passt. Die richtige Auswahl sollte man aber sorgfältig abwägen. Dazu gibt es einige Anregungen und Empfehlungen, die zu beachten sind: Wie steht es um zum Beispiel die Verfügbarkeit, die Zuverlässigkeit, die Erweiterbarkeit oder um die Möglichkeiten der Wartung und der Sicherheit?

Zur Verfügbarkeit stellt sich die Frage: Gibt die ausgewählte Lösung Zugriff auf den bestehenden Cobol-Prozess und/oder ist eine externe Middleware notwendig?

Bei der Zuverlässigkeit sollte geklärt werden: Passt diese Lösung in eine zuverlässig unterstütze Infrastruktur? Wird eine etablierte Technologie eingesetzt oder sind hausgemachte Erweiterungen notwendig, um die Funktionen zu nutzen, die der Lieferant anbietet?

Wie steht es mit möglichen Erweiterungen? Kann die Lösung mit Industrial-Standard-Modellen einfach erweitert werden? Wenn die Erweiterung in Java erfolgt, handelt es sich um eine Standard-Java-Fähigkeit? Wird ein Browser Plug-in eingesetzt, garantiert es die Verwendung von Standard-Browser-Richtlinien?

Zur Wartung sollte geprüft werden: Passt die Lösung in einen definierten Codierungs- und Ausführungsprozess? Stimmen die Wartungsprozeduren mit ähnlichen Prozessen für Updates und Verbesserungen überein?

Und „last not least“: Beinhaltet oder reduziert die Lösung die Sicherheit der eingesetzten Ausführungsbedingungen? Wird eine andere Lücke oder ein anderer Mechanismus eingeführt, der die Sicherheit verletzt?

LegacyJ Vertriebsbüro Deutschland

D–61273 Wehrheim

Telefon: (+49) 06081/68269-21

www.legacyj.com