Die Erfahrung der Migration Legacy Cobol / PL1 auf Java

StackOverflow https://stackoverflow.com/questions/1029974

Frage

ORIGINAL Q: Ich frage mich, ob jemand Erfahrung der Migration eine große Cobol / PL1 Code-Basis zu Java hat?

Wie automatisiert war, den Prozess und wie wartbar war der Ausgang?

Wie hat der Wechsel von Transaktions zu OO trainieren?

Jede Lektionen auf dem Weg oder Ressourcen / White Papers gelernt, dass der Nutzen würde geschätzt werden können.

EDIT 7/7: Gewiß, der NACA Ansatz interessant ist, die Möglichkeit, Ihren BAU Änderungen an den COBOL-Code weiterhin bis zu dem Punkt, die Java-Version der Freigabe hat Verdienst für jede Organisation.

Das Argument für verfahrens Java im gleichen Layout wie die COBOL-Programmierer die ein Gefühl von Komfort zu geben, während sie mit der Java-Sprache vertraut zu machen für eine große Organisation mit einer großen Code-Basis ein gültiges Argument ist. Wie @Didier die 3mil $ Jahr betont Einsparung auf jedem BAU Rahmen für die großzügige Polsterung gibt Änderungen für die Zukunft des Code auf einer laufenden Basis Refactoring. Wie er sagt, wenn Sie Ihre Mitarbeiter kümmern finden Sie einen Weg, um sie glücklich zu halten, während sie nach und nach herausfordernd.

Das Problem, wie ich es mit dem Vorschlag von @duffymo zu

siehe
  

Am besten zu versuchen und wirklich zu verstehen, die   Problem an der Wurzel und wieder ausdrücken   als ein objektorientiertes System

ist, dass, wenn Sie BAU haben laufend ändert sich dann während der langen Projektlaufzeit Ihres neuen OO-System der Codierung Sie am Ende Codierung und Testen von Änderungen an der Doppel. Das ist ein großer Vorteil des NACA-Ansatzes. Ich habe einige Erfahrung der Migration Client-Server-Anwendungen auf eine Web-Implementierung hatte und dies war eine der wichtigsten Fragen, die wir angetroffen, stetig steigenden Anforderungen aufgrund BAU ändert verschiebt. Es machte PM & eine echte Herausforderung planen.

Dank @hhafez, die Erfahrung ist schön wie „ähnlich, aber etwas anders“ gesetzt wird und hat eine einigermaßen zufriedenstellende Erfahrung einer automatischen Code-Migration von Ada auf Java hat.

Danke @Didier für einen Beitrag, ich bin Ihr Ansatz noch studieren und wenn ich irgendein Q habe ich es eine Linie fallen.

War es hilfreich?

Lösung

25.06 aktualisieren: Ein Freund lief nur über die NACA Cobol zu Java-Konverter. Sieht sehr interessant wurde es verwendet, 4m Zeilen Cobol mit 100% Genauigkeit zu übersetzen. Hier ist die NACA Open-Source-Projektseite . Die anderen Wandler Ich habe waren proprietäre gesehen, und die Materialien fehlten auffallend Erfolgsgeschichten und detaillierten Beispielcode. NACA lohnt einen langen Blick.

04.07 aktualisieren: @Ira Baxter berichtet, dass die Java-Ausgabe sieht sehr Cobol-esque, das es absolut der Fall ist. Für mich ist dies das natürliche Ergebnis der automatischen Übersetzung. Ich bezweifle, dass wir immer einen viel besseren Übersetzer finden. Dies ist vielleicht argumentiert für eine schrittweise Wiederschreib Ansatz.

Aktualisieren 2/7/11: @spgennard weist darauf hin, dass es einige Cobol Compiler auf der JVM sind zum Beispiel Veryant der isCOBOL Evolve . Diese könnten verwendet werden, nach und nach, um die Code-Basis übergehen, obwohl ich denke, die OP war mehr daran interessiert, in automatisierten Quellen Konvertierung.

würde ich darüber sehr vorsichtig sein. (Ich habe für ein Unternehmen zu arbeiten, dass automatisch korrigiert Cobol und PL / I-Programme für Y2K, und tat den Front-End-Compiler, der viele Dialekte von Cobol in unsere Zwischen analytischer Form umgewandelt, und auch ein Code-Generator Mein Sinn.) ist, dass Sie mit einer Java-Code-Basis aufzuwickeln würden, die noch unelegant und unbefriedigend wären, mit zu arbeiten. Sie können mit Performance-Problemen, Abhängigkeiten von Hersteller bereitgestellte Bibliotheken aufzuwickeln, generierten Code, der Buggy ist, und so weiter. Sie werden sicherlich eine große Test Rechnung entstehen.

von Grund auf neu starten mit einem neuen objektorientiertes Design kann der richtige Ansatz sein, aber Sie auch sorgfältig die Jahrzehnte gespeichertem Wissen durch die Code-Basis dargestellt berücksichtigen müssen. Oft gibt es viele Feinheiten, die den neuen Code verpassen kann. Auf der anderen Seite, wenn Sie eine harte Zeit die Suche nach qualifiziertem Personal sein mit dem Legacy-System aufrecht zu erhalten, ist möglicherweise keine andere Wahl hat.

Ein abgestufter Ansatz wäre, zunächst zu Cobol-Upgrade 97. Dies fügt Objektorientierung, so dass Sie neu schreiben können und refactor Subsysteme einzeln, wenn Sie neue Funktionen hinzufügen. Oder Sie könnten einzelne Subsysteme ersetzen mit frisch geschriebenen Java.

Manchmal werden Sie in der Lage sein, Komponenten zu ersetzen, mit off-the-shelf-Software: wir eine sehr große Versicherungsgesellschaft dazu beigetragen, die noch 2m Codezeilen in einer Legacy-Sprache hatte es in den 1950er Jahren geschaffen. Ich konvertierte die Hälfte davon konforme Legacy Sprache Y2K, und sie ersetzt die andere Hälfte mit einem modernen Abrechnungssystem sie von einem externen Anbieter gekauft.

Andere Tipps

Es war klar unsere Absicht ursprünglichen Java-Code zu erhalten, die sehr nahe am Original COBOL, um die Migration von Menschen zu erleichtern war. Sie die guten alten app sie in genau die gleichen Struktur in COBOL geschrieben finden

eines unserer wichtigsten Ziele war Anfangs-Entwickler an Bord zu haben: das ist die Art, wie wir es erreichen gefunden. Wenn Anwendung auf Java migriert, können diese Menschen beginnen sie mehr OO machen, wie sie sich weiterentwickeln / es Refactoring.

Wenn Sie nicht über die Migration Menschen kümmern, können Sie andere Strategie verwendet werden.

Diese 1-zu-1-Umsetzung machte auch 100% automatische Konvertierung einfacher und schneller: die gute Folge davon ist, dass wir unsere wiederkehrenden Einsparungen (3 Millionen Euro / Jahr) deutlich schneller gemacht: wir schätzen, 12-18 Monate. Diese frühen Einsparungen deutlich in OO Refactoring reinvestiert

fühlen Sie sich frei, mich zu kontaktieren: didier.durand@publicitas.com oder mediaandtech@gmail.com

didier

Meine Erfahrung ist ähnlich, aber etwas anders. Wir haben eine große und alte Code-Basis in Ada (0.5Mloc über 15 + Jahre), die auf Java vor kurzem umgebaut wurde. Es wurde an ein Unternehmen ausgelagert, die Kombination von automatisierter / manueller Konvertierung zur Verfügung gestellt. Sie haben die Prüfung überprüfen auch, dass die Ada und Java-Systeme das gleiche verhalten hat.

Einige Teile davon, wo 95 in Ada geschrieben (dh die Möglichkeit der OOP hatte), aber das meiste davon war nicht

Nun ja ist der Code nicht auf die gleichen Standards des Code bis in erster Linie in Java geschrieben, aber wir haben es wurden unter Verwendung seitdem erfolgreich (18 Monate) ohne größere Probleme. Der große Vorteil, den wir bekamen, war jetzt können wir mehr Entwickler finden unsere Code-Basis mit den Fähigkeiten zu halten wartbaren Code zu erzeugen. (Jeder kann in Ada entwickeln, aber wie jede anderen Sprache, wenn Sie nicht über die Erfahrung in der es Sie mit wartbaren Code können am Ende)

Aus Risikovermeidung Sicht macht der NACA Ansatz absolut Sinn. Wiederverwenden ihre Werkzeuge auch nicht. Sie nutzten die Entwicklung der Werkzeuge, um ihre Leute in Java und Linux bis zu Geschwindigkeit zu bekommen.

Das Ergebnis der NACA Umwandlung wird nicht gut genug sein, oder sogar OO, und macht es schwierig, neue Leute zu mieten. Aber es testbar ist, kann Refactoring werden, und Sie können in einem besseren Übersetzer stecken.

[Bearbeiten] Ira, Sie scheinen nicht sehr risikobewusst zu sein.

Das Senden des COBOL-Programmierers auf einen Java-Kurs wird nicht sie schreibt nutzbaren objektorientierten Code zu machen. Das dauert ein paar Jahren. Während dieser Zeit wird die Produktivität sehr niedrig sein, und Sie können im Grunde alle den Code wegzuwerfen sie das erste Jahr schreiben. Darüber hinaus werden Sie 10-20% Ihrer Programmierer verlieren, die von dem Übergang nicht bereit oder in der Lage sind. Viele Leute mögen nicht zurück zum Anfänger-Status geht, und es wird die Hackordnung beeinflussen, da einige Programmierer die neue Sprache viel schneller als andere abholen.

Der NACA-Ansatz ermöglicht es dem Unternehmen, weiter zu arbeiten, und stellt keinen unnötigen Druck auf die Organisation. Der Zeitplan für die Umwandlung ist unabhängig. einen separaten Übersetzer, in java, writen von OO-Experten ermöglicht eine allmähliche Einwirkung von Java für das alte Team zu haben. Das Schreiben der Testfälle erhöht Domänenwissen in dem neuen Java-Team.

Das eigentliche oo System ist der Übersetzer, und das ist der Ort, in besseren Übersetzern zu stopfen. Machen Sie es einfach, das zu tun, und Sie haben nicht den generierten Code zu berühren. Wenn der generierte Code hässlich genug ist, ist es das, was automatisch geschieht:)

  • die alten Programmierer den COBOL-Eingang ändern;
  • die neuen Java-diejenigen, die Übersetzer ändern.

[die Übersetzer einmal läuft] ist eine schlechte Strategie. Tun Sie das nicht. Und wenn Sie den erzeugten Code bearbeiten müssen, halten ein Mapping zurück. Das kann automatisiert werden. Und sollte es sein. Es ist viel einfacher, diese Art von Dingen in einem Smalltalk Bild zu tun, aber man kann es mit Dateien. Es gibt Menschen mit viel Erfahrung verschiedene Ansichten auf demselben Artefakt beibehalten: Chip-Designer in den Sinn kommen

.

Der Übersetzer instrumentiert werden soll, so dass Sie die täglichen Zählungen beispiel erstellen können.

  • COBOL-Eingabekomponenten;
  • OO Java-Eingabekomponenten;
  • COBOL-Stil Ausgabekomponenten;
  • OO Stil Ausgabekomponenten.

Sie können lesen möchten: Peter van den Hamer & Kees Lepoeter (1996) Managing Design Data: Die fünf Dimensionen des CAD-Frameworks, Configuration Management und Datenmanagement, Proceedings of the IEEE, Vol. 84, No. 1, Januar 1996

[Cobol-Plattformen zu bewegen] Der Umzug von Cobol auf dem Mainframe auf Windows / Linux COBOL könnte eine tragfähige Strategie für das NACA-Team hat, aber die Frage war, um zu Java zu bewegen. Wenn das langfristige Ziel ist es, ein modernes OO-System zu haben, und um dorthin zu gelangen mit so wenig operationelle Risiko wie möglich, ist der NACA Ansatz Sound. Es ist nur ein Schritt, though. Viele Refactoring wird folgen.

Ich bin überrascht, niemand hat Semantic Design-DMS Software Reengineering Toolkit erwähnt. Ich sah in COBOL Konvertierung in der Vergangenheit. Ich arbeitete an „automatische Programmierung“ damals. Bevor Sie einen Übersetzer zu schreiben, sah ich in diesem Bereich eine Reihe von früheren Bemühungen und Produkten auf. Semantic Designs' GLR-basiertes Tool war das beste der Gruppe.

Das war vor vielen Jahren. Zu der Zeit, übersetzte das Werkzeug COBOL zu einer modernen Sprache, es Refactoring, hübsch es gedruckt, usw. Hier ist der Link, um es jetzt.

http://www.semdesigns.com/Products/DMS/DMSToolkit.html

Sie sind immer noch herum. Sie haben das Werkzeug erweitert. Es ist allgemeiner. Es könnte helfen, Menschen automatisierte Konvertierungen zu tun oder ein Konvertierungstool anpassen. Es wurde entwickelt, erweiterbar und modifizierbar zu sein, ähnlich zu dem, was Stephan hingewiesen. Dank Cyrus auch für SoftwareMining zu erwähnen. Ich werde auch in sie aussehen, wenn ich in eine COBOL-Migration in der Zukunft führen.

Sie sprechen von Reengineering . Die gute Sache ist, dass viele Menschen weltweit versucht, dies zu tun. Das Schlimme ist, dass es eine Menge von Problemen in Bezug auf Legacy-Anwendungen Reengineering ist. Ausgehend von fehlenden Quellen und bis hin zu komplexen Algorithmen aus Compilerbau und Graphentheorie Feldern

Idee der automatischen Übersetzung ist sehr beliebt, bis Sie etwas zu konvertieren versuchen. In der Regel das Ergebnis ist schrecklich und wartbaren. Es ist mehr wartbaren als Original komplizierte Anwendung. Aus meiner Sicht, dass jedes Werkzeug aus Legacy moderner Sprache automatische Übersetzung ermöglicht, ist sehr Marketing orientiert: Es sagt genau das, was die Leute hören wollen, als Sie „übersetzen Ihre Anwendung von ... auf Java einmal und vergessen!“ Kauf einen Vertrag, und Sie dann verstehen, dass Sie sehr fest auf dem Werkzeug hängt (weil Sie keine Änderung Ihrer Anwendung, ohne sie machen können!).

Alternative Ansatz ist „Verstehen“: das Werkzeug, das Sie sehr detailliertes Verständnis Ihrer Legacy-Anwendung ermöglicht. Und Sie können es für die Wartung verwenden oder für die Dokumentation oder für neue Plattform neu zu erfinden.

Ich weiß ein wenig über Modernization Workbench Geschichte vor Microfocus es im letzten Jahr gekauft und bewegt Entwicklung in ein anderes Land. Es war eine große Anzahl komplexer Analysetools und die Anzahl der unterstützten Zielsprachen (einschließlich Java). Aber kein Kunde wirklich automatische Codegenerierung verwendet, so dass die Entwicklung des Erzeugungsteils wurde eingefroren. Soweit ich weiß, PL / I-Träger wurde meist umgesetzt, aber es wurde nie beendet. Aber noch können Sie versuchen, kann dies, was Sie suchen.

Ich sah sie nur an der NACA-Seite und docs. Aus ihrer Dokumentation:

"Die generierte Java verwendet eine Cobol-ähnliche Syntax. Es ist so nah wie möglich von der ursprünglichen Cobol-Syntax innerhalb natürlich die Grenzen der Sprache Java. Generierter Code sieht nicht wie klassische native Java und ist nicht Objekt aus der Anwendung Sicht orientiert. Dies ist eine durch starke Wahl entwerfen, eine reibungslose Migration von Cobol-Entwickler der Java-Umgebung zu ermöglichen. Das Ziel ist, betriebswirtschaftliche Kenntnisse in der Hand des Menschen zu halten, die die ursprünglichen Cobol Programme geschrieben hat. "

Ich habe ein Beispiel nicht, aber das Zitat gibt einen starken Geschmack des Ergebnisses. Seine COBOL codiert in Java.

Sie können immer einen „Übersetzer“ von einer Sprache in einer anderen bauen, durch einfach Codieren eines Dolmetschers im Ziellangauge. Das ist meiner Meinung nach ein absolut schreckliche Art und Weise ein Langauge zu übersetzen, wie Sie mit am Ende das Schlimmste aus beiden Welten: Sie müssen nicht den Wert der neuen Sprache erhalten, und Sie müssen noch die Kenntnis der alten haben, um das Ergebnis zu halten am Leben. (Kein Wunder, dass diese Sache ein „Transcoder“ genannt wird, ich würde nie dieser Begriff schon einmal gehört).

Das Argument für diesen Trick ist es, die Kosten für die Mainframe-dump. Wo ist der Beweis dafür, dass die Kosten für das konvertierte Programm der Arbeits nicht die Einsparungen überschwemmen? Ich vermute, dass die Wahrheit ist, dass die Operationen Menschen Senkte ihre Kosten durch den Mainframe-Dumping und sie konnten es nicht wurscht dass die Wartungsaufgaben bekam teurer. Dies kann zwar rational sein für die Operationen Jungs, es ist eine dumme Wahl für die orgnization als Ganzes.

Der Himmel den Menschen helfen, die Opfer dieses Werkzeugs sind.

EDIT Mai 2010: ich ein Beispiel von NACA der Ausgang gefunden; einer von ihre Testfälle. Das ist absolut großartig JOBOL. Es ist eine gute Sache, die sie sind halten ihre COBOL-Programmierer und wollen nicht mieten alle Java-Programmierer. Als Ihr diese Zeilen lesen, werden Sie sicher erinnern dies ist Java Code. 

/*
 * NacaRTTests - Naca Tests for NacaRT support.
 *
 * Copyright (c) 2005, 2006, 2007, 2008 Publicitas SA.
 * Licensed under GPL (GPL-LICENSE.txt) license.
 */

import idea.onlinePrgEnv.OnlineProgram;
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();
  }

Kinder: Dies wird nur von Fachleuten durchgeführt. versuchen, dies nicht zu Hause.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top