Warum COBOL-zu-Java-Konverter „Jobol“ erzeugen und wie man dies vermeiden kann

Die Umstellung war nach drei Monaten abgeschlossen. Die Java-Anwendung ließ sich kompilieren, bestand die grundlegenden Funktionstests und wurde für den Einsatz freigegeben. Sechs Monate nach Produktionsbeginn bemerkte das Plattformteam ein Problem: Niemand im Java-Team konnte den Code warten. Die Code-Reviews dauerten doppelt so lange wie übliche Java-Reviews. Die Fehlerberichte bezogen sich auf Konzepte wie WORKING-STORAGE, PROCEDURE DIVISION-Logik und Konventionen für gepackte Dezimalfelder, die Java-Entwickler ohne Mainframe-Erfahrung nicht nachvollziehen konnten. Die Anwendung war zwar von COBOL nach Java konvertiert worden, doch das resultierende Java-Programm dachte, strukturierte und verhielt sich wie COBOL. Es war ein „Jobol“.

Jobol (manchmal auch JOBOL geschrieben) ist ein Kofferwort für Java-Code, der die prozedurale Semantik von COBOL beibehält, ohne die objektorientierten Möglichkeiten von Java zu nutzen. Jason Bloomberg, Gründer des Analysehauses Intellyx, definierte es folgendermaßen: Jobol ist technisch gültiger Java-Code, der die ursprüngliche Softwarearchitektur beibehält und die COBOL-Semantik bewahrt. Entwickler müssen den Java-Code daher wie COBOL behandeln. Die entscheidende Konsequenz ist unmittelbar: Ein Unternehmen, das COBOL in Jobol umwandelt, ist nicht von der Notwendigkeit von COBOL-Expertise befreit. Es verlagert diese Expertise lediglich in eine Sprache, die die im Code enthaltenen COBOL-Muster nicht nativ unterstützt. Es entsteht ein System, das schwieriger zu warten ist als das ursprüngliche COBOL und keine der erwarteten Java-Vorteile bietet.

Wie Jobol tatsächlich aussieht

Bevor die Ursachen analysiert werden können, muss das Muster erkennbar sein. Hier ist dieselbe Geschäftslogik – eine Bonitätsprüfung eines Kunden – in drei Varianten dargestellt: im ursprünglichen COBOL-Code, im Jobol-Code, den automatisierte Konvertierer typischerweise erzeugen, und im idiomatischen Java-Code, der durch eine fachgerechte Modernisierung entsteht.

Das ursprüngliche COBOL:

Cobol

       PERFORM-CREDIT-CHECK.
           MOVE WS-CUST-ID TO DB-CUST-KEY
           READ CUSTOMER-FILE KEY IS DB-CUST-KEY
               INVALID KEY
                   MOVE 'NOT FOUND' TO WS-STATUS
                   PERFORM HANDLE-MISSING-CUSTOMER
           END-READ

           IF CUST-CREDIT-SCORE < 650
               MOVE 'DECLINED' TO WS-CREDIT-RESULT
               MOVE 'Score below threshold' TO WS-DECLINE-REASON
           ELSE IF CUST-OUTSTANDING-BALANCE > CUST-CREDIT-LIMIT
               MOVE 'DECLINED' TO WS-CREDIT-RESULT
               MOVE 'Balance exceeds limit' TO WS-DECLINE-REASON
           ELSE
               MOVE 'APPROVED' TO WS-CREDIT-RESULT
           END-IF.

Der von einem zeilenweisen Konverter erzeugte Jobol:

Java

// Jobol: procedural COBOL logic mapped directly to Java
// No OOP, no encapsulation, static global state, COBOL naming conventions
public class CreditCheckProgram {
    static String WS_CUST_ID;
    static String DB_CUST_KEY;
    static String WS_STATUS;
    static String WS_CREDIT_RESULT;
    static String WS_DECLINE_REASON;
    static int CUST_CREDIT_SCORE;
    static double CUST_OUTSTANDING_BALANCE;
    static double CUST_CREDIT_LIMIT;

    public static void PERFORM_CREDIT_CHECK() {
        DB_CUST_KEY = WS_CUST_ID;
        Customer customer = CustomerFile.read(DB_CUST_KEY);
        if (customer == null) {
            WS_STATUS = "NOT FOUND";
            HANDLE_MISSING_CUSTOMER();
            return;
        }
        CUST_CREDIT_SCORE = customer.getCreditScore();
        CUST_OUTSTANDING_BALANCE = customer.getOutstandingBalance();
        CUST_CREDIT_LIMIT = customer.getCreditLimit();

        if (CUST_CREDIT_SCORE < 650) {
            WS_CREDIT_RESULT = "DECLINED";
            WS_DECLINE_REASON = "Score below threshold";
        } else if (CUST_OUTSTANDING_BALANCE > CUST_CREDIT_LIMIT) {
            WS_CREDIT_RESULT = "DECLINED";
            WS_DECLINE_REASON = "Balance exceeds limit";
        } else {
            WS_CREDIT_RESULT = "APPROVED";
        }
    }
}

Das idiomatische Java, das eine geschickte Modernisierung hervorbringt:

Java

// Idiomatic Java: domain model, encapsulation, value objects, Spring service
@Service
public class CreditCheckService {

    private final CustomerRepository customerRepository;

    public CreditCheckService(CustomerRepository customerRepository) {
        this.customerRepository = customerRepository;
    }

    public CreditDecision check(CustomerId customerId) {
        Customer customer = customerRepository.findById(customerId)
            .orElseThrow(() -> new CustomerNotFoundException(customerId));

        if (customer.creditScore() < CreditThresholds.MINIMUM_SCORE) {
            return CreditDecision.declined("Score below threshold");
        }
        if (customer.outstandingBalance().compareTo(customer.creditLimit()) > 0) {
            return CreditDecision.declined("Balance exceeds limit");
        }
        return CreditDecision.approved();
    }
}

Die Jobol-Variante umfasst 32 Zeilen statischen globalen Zustands, ist prozedural strukturiert, verwendet COBOL-Namen und lässt sich ohne vorherige Initialisierung des globalen Klassenzustands nicht testen. Die idiomatische Variante hingegen ist 20 Zeilen lang, injizierbar, testbar und für jeden Java-Entwickler ohne COBOL-Kenntnisse sofort verständlich. Beide implementieren dieselben Geschäftsregeln. Nur eine davon ist für das Team, das durch die Modernisierung unterstützt werden sollte, wartungsfähig.

Die sechs Jobol-Muster und warum Verarbeiter sie produzieren

Muster 1: Globaler statischer Zustand ersetzt WORKING-STORAGE

Der Arbeitsspeicherbereich (Working Storage Section, WS) von COBOL speichert Programmvariablen, die über PERFORM-Aufrufe hinweg erhalten bleiben. Er repräsentiert den gemeinsamen, veränderlichen Zustand des Programms; jeder Abschnitt liest und schreibt dieselben WS-Variablen. Automatische Konverter bilden dies direkt auf statische Java-Felder einer einzelnen Klasse ab und erhalten so die Semantik des gemeinsamen Zustands, verletzen aber gleichzeitig alle Java-Kapselungsprinzipien.

Warum Konverter das tun: Die Zuordnung von Arbeitsspeicher zu statischen Feldern ist eine mechanische Eins-zu-Eins-Transformation. Der Konverter versteht nicht, dass Javas Kapselungsmodell den gemeinsam genutzten Zustand auf Programmebene durch Instanzvariablen, Methodenparameter und Rückgabewerte ersetzt. Er konvertiert, was er sieht, ohne zu verstehen, warum die ursprüngliche Struktur existierte.

Die Folge: Statischer Zustand ist isoliert nicht testbar, ohne explizite Synchronisierung threadsicher und strukturell identisch mit dem ersetzten COBOL-Code. Jeder Entwickler, der Parallelverarbeitung in das System integrieren möchte, muss zunächst den statischen Zustand entwirren – eine Aufgabe, die bei der Umstellung auf alle nachfolgenden Wartungsteams delegiert wurde.

Die Lösung: Ordnen Sie WORKING-STORAGE-Variablen basierend auf ihrem Verwendungsbereich Instanzfeldern, Methodenparametern oder Rückgabewerten zu. Variablen, die nur innerhalb eines Absatzes verwendet werden, werden zu lokalen Variablen. Variablen, die zwischen Absätzen übergeben werden, werden zu Methodenparametern oder Rückgabewerten. Variablen, die den Zustand eines gemeinsam genutzten Objekts repräsentieren, werden zu Instanzfeldern einer korrekt gekapselten Domänenklasse.

Muster 2: PERFORM-Ketten werden zu langen statischen Methoden

COBOL-Programme sind als PERFORM-Ketten organisiert. Die Hauptprozedur führt eine Sequenz benannter Paragraphen aus, von denen jeder weitere Paragraphen aufrufen kann. Automatische Konverter übersetzen jeden Paragraphen in eine statische Methode und jeden PERFORM-Aufruf in einen Aufruf einer statischen Methode. Das Ergebnis ist eine einzelne Klasse mit Dutzenden von statischen Methoden, die sich über einen Aufrufgraphen, der die COBOL-PERFORM-Struktur widerspiegelt, gegenseitig aufrufen.

Java

// Jobol: PERFORM chain mapped to static method calls
public class ProcessOrderProgram {
    public static void main() {
        validateOrder();
        checkInventory();
        calculateTotal();
        applyDiscounts();
        processPayment();
        generateConfirmation();
        updateInventory();
    }

    public static void validateOrder() { /* ... */ }
    public static void checkInventory() { /* ... */ }
    // ... 40 more static methods
}

Warum Konverter das tun: Die strukturelle Zuordnung von COBOL-Absatz zu Java-Methode ist direkt. Der Konverter erkennt korrekt, dass PERFORM „diese Codeeinheit aufrufen“ bedeutet. Was er jedoch übersieht, ist, dass das Java-Objektmodell Code um Domänenentitäten herum organisiert, nicht um Verarbeitungsschritte.

Die Reparatur: Identifizieren Sie die in der PERFORM-Kette eingebetteten Domänenkonzepte. validateOrder, calculateTotal und applyDiscounts sind Operationen an einem Auftrag. processPayment ist eine Operation im Zahlungskontext. checkInventory und updateInventory Es handelt sich um Operationen auf dem Inventar. Durch das Refactoring werden die statischen Methoden den zugehörigen Domänenklassen zugeordnet, wodurch eine lange prozedurale Aufrufkette durch eine kurze Orchestrierungsmethode ersetzt wird, die an die entsprechenden Domänenobjekte delegiert.

Muster 3: Numerische Datentypen ohne präzise Verarbeitung

Die gepackten Dezimalfelder (COMP-3) von COBOL ermöglichen exakte Dezimalarithmetik. Konverter, die COMP-3 auf Java abbilden. double or float Sie führen systematische Gleitkomma-Rundungsfehler ein, die sich über Millionen von Finanztransaktionen summieren.

Java

// Jobol: COMP-3 mapped to double (wrong)
static double WS_TRANSACTION_AMOUNT;  // Was PIC S9(9)V99 COMP-3
static double WS_RUNNING_TOTAL;

// After 10M additions of 0.1:
// Expected: 1,000,000.00
// Actual:   1,000,000.0000000002 (floating point accumulation)

Java

// Idiomatic Java: COMP-3 mapped to BigDecimal (correct)
private BigDecimal transactionAmount;  // Preserves decimal precision
private BigDecimal runningTotal;

// After 10M additions of 0.1:
// Result: exactly 1,000,000.00

Warum Umrichter das tun: double ist der Standard-Zahlentyp in Java. Ein Konverter, der die COMP-3-Semantik nicht explizit versteht, verwendet standardmäßig den gebräuchlichsten Java-Zahlentyp, was für exakte Dezimalarithmetik die falsche Wahl ist.

Die Reparatur: Jedes COMP-3-Feld ist zugeordnet zu BigDecimalJede numerische Berechnung, die COMP-3-Werte beinhaltet, verwendet BigDecimal Arithmetik. Die scale() BigDecimal entspricht den impliziten Dezimalstellen in der PIC-Klausel: PIC S9(9)V99 hat 2 implizite Dezimalstellen, entsprechend BigDecimal mit Skala 2.

Muster 4: EBCDIC-Zeichenketten und Byte-Array-Relikte

COBOL verarbeitet Zeichendaten als Zeichenketten fester Länge mit Leerzeichenauffüllung in EBCDIC-Kodierung. Konverter erzeugen oft Java-Code, der die Semantik der Zeichenketten fester Länge und mit Leerzeichen aufgefüllter Zeichenketten auch nach der Konvertierung nach UTF-8 beibehält, was dazu führt, dass Java Zeichenketten so verarbeitet wie ein Mainframe-Programmierer der 1970er Jahre.

Java

// Jobol: preserves COBOL fixed-length string handling
static char[] WS_CUSTOMER_NAME = new char[40]; // Was PIC X(40)
static char[] WS_CUSTOMER_ADDR = new char[80]; // Was PIC X(80)

// COBOL-style space-padding comparison
if (new String(WS_CUSTOMER_NAME).trim().equals("SMITH")) { ... }

// COBOL-style string concatenation with padding
System.arraycopy(name.toCharArray(), 0, WS_CUSTOMER_NAME, 0,
                 Math.min(name.length(), 40));

Java

// Idiomatic Java: proper String types and domain objects
private String customerName;  // Trim on read, no padding
private String customerAddress;

// Clean comparison
if ("Smith".equalsIgnoreCase(customer.name())) { ... }

Warum Konverter das tun: Die COBOL PIC X(40)-Definition hat eine Länge, die der Konverter als Java-Arraygröße beibehält. Die EBCDIC-zu-UTF-8-Konvertierung kann zwar durchgeführt werden, die Semantik der festen Länge wird jedoch unnötigerweise übernommen.

Die Reparatur: Karte PIC X(n) Felder zu String Objekte werden beim Lesen gekürzt und Längenbeschränkungen entfernt. Längenbeschränkungen sind nur an Persistenzgrenzen (Datenbankspaltenlängen, Dateiformatpositionen) relevant, nicht im Domänenmodell.

Muster 5: Fehlerbehandlung über Statuscodes

COBOL kommuniziert Fehlerzustände über Statuscodes: FILE STATUS, SQLCODE, RETURN-CODE. Konverter erhalten dieses Muster in Java und erzeugen Code, der nach jeder Operation ganzzahlige Statuscodes prüft, anstatt das Ausnahmemodell von Java zu verwenden.

Java

// Jobol: COBOL status code pattern in Java
static int WS_FILE_STATUS;
static int WS_SQL_CODE;

CustomerFile.read(DB_CUST_KEY);
WS_FILE_STATUS = CustomerFile.getLastStatus();
if (WS_FILE_STATUS == 10) {
    // Not found
} else if (WS_FILE_STATUS == 35) {
    // File not available
} else if (WS_FILE_STATUS != 0) {
    // Unknown error
}

Java

// Idiomatic Java: exceptions for error conditions
try {
    Customer customer = customerRepository.findById(customerId)
        .orElseThrow(() -> new CustomerNotFoundException(customerId));
    // process customer
} catch (DatabaseUnavailableException e) {
    log.error("Database unavailable during credit check", e);
    throw new CreditCheckServiceException("Service temporarily unavailable", e);
}

Warum Konverter das tun: Die Statuscodeprüfung ist ein COBOL-Muster; die Umwandlung in eine Java-Methode, die ein Statusfeld zurückgibt oder setzt, ist eine rein mechanische Transformation. Zu erkennen, dass Java-Ausnahmen das idiomatische Äquivalent darstellen, erfordert architektonisches Urteilsvermögen, keine mechanische Übersetzung.

Die Reparatur: Ordnen Sie COBOL-Fehlerbedingungen Java-Ausnahmen zu. FILE STATUS 10 (Datensatz nicht gefunden) wird zu Optional.empty() oder eine domänenspezifische Ausnahme. SQLCODE-Fehler werden zu typisierten Datenbankausnahmen. Die Java-Codestruktur spiegelt die Absicht wider: try/catch-Blöcke für erwartete Fehlermodi, ungeprüfte Ausnahmen für unerwartete.

Muster 6: Monolithische Klassenstruktur

COBOL-Programme sind von Natur aus monolithisch; ein einzelnes Programm verarbeitet eine gesamte Geschäftsfunktion. Konverter erzeugen pro COBOL-Programm eine einzelne Java-Klasse, wodurch Java-Klassen entstehen, die Tausende von Zeilen lang sein können und mehrere Aufgaben übernehmen, die in einem objektorientierten Design auf mehrere spezialisierte Klassen verteilt würden.

Warum Konverter das tun: Ein COBOL-Programm wird einer Java-Klasse zugeordnet; die Übersetzungseinheit des Konverters ist das Programm. Die interne Struktur des Programms (seine Paragraphen, Abschnitte, PERFORM-Ketten) wird ohne Zerlegung in kleinere Klassen zur internen Struktur der Klasse.

Die Lösung: Wenden Sie das Prinzip der Einzelverantwortung auf jede konvertierte Klasse an. Eine 3,000 Zeilen lange Jobol-Klasse, die Eingaben validiert, Daten aus einer Datenbank liest, Geschäftsregeln anwendet, Ausgaben formatiert und in eine Datei schreibt, sollte in Folgendes aufgeteilt werden: einen Eingabevalidator, ein Repository, einen Domänendienst, einen Formatierer und einen Schreiber. Jede dieser Komponenten ist isoliert testbar und auf eine einzige Aufgabe fokussiert.

Die Voraussetzung für die Strukturanalyse

Jedes Jobol-Muster hat ein entsprechendes Refactoring. Dieses Refactoring kann jedoch nicht vom Konverter angewendet werden; es erfordert ein Verständnis der Programmfunktionalität, bevor über die Umstrukturierung entschieden werden kann. Genau dieses Verständnis liefert die Strukturanalyse des COBOL-Quellcodes vor dem Ausführen eines Konvertierungstools.

Konkret liefert die Strukturanalyse die Eingangsdaten, die für Umwandlungsentscheidungen benötigt werden:

Inventar der Geschäftslogik. Die vollständige Auflistung aller EVALUATE-Bedingungen, IF-Zweige und COMPUTE-Formeln in jedem Programm – also was das Programm entscheidet, nicht nur seine Struktur. Dieses Inventar ist die Spezifikation, die der refaktorierte Java-Code erfüllen muss. Ein Programm mit 847 EVALUATE-Bedingungen benötigt eine Zielklassenstruktur, die 847 Entscheidungspunkte aufnehmen kann; die Ausgabe des Konverters ist der Ausgangsentwurf, nicht das fertige Produkt.

Abhängigkeitsgraph. Welche Programme rufen welche anderen Programme auf? Die PERFORM-Kette, die sich über mehrere COBOL-Programme erstreckt, wird in Java zu einem Serviceaufrufgraphen. Der Abhängigkeitsgraph bestimmt, welche Programme unabhängig voneinander refaktoriert werden können (wenige eingehende Abhängigkeiten) und welche als koordinierte Gruppen refaktoriert werden müssen (viele gemeinsame Abhängigkeiten über Copybooks oder gemeinsam genutzte Daten).

Identifizierung von totem Code. Absätze und Abschnitte, die in der Produktionsumgebung niemals ausgeführt werden, gelten als toter Code und sollten im konvertierten Java-Code nicht vorkommen. Konverter, die toten Code einbeziehen, vergrößern die konvertierte Codebasis und erhöhen den nachfolgenden Refactoring-Aufwand.

Datenmodellwiederherstellung. Die VSAM-FD-Einträge, DB2-Tabellendefinitionen und Copybook-Strukturen definieren die Programmdaten. Jede COBOL-Datenstruktur ist einem oder mehreren Java-Domänenobjekten zugeordnet; die Zuordnung wird durch das Datenmodell und nicht durch die Feldnamen in WORKING-STORAGE bestimmt.

Analyseeingabe	Die Konversionsentscheidung, die sie antreibt
AUSWERTEN/WENN Zweiganzahl	Domänenklassenzerlegung, wie viele Entscheidungsfälle jeder Dienst bearbeitet
Anzahl der eingehenden Abhängigkeiten	Refactoring-Reihenfolge, zuerst die Programme mit den wenigsten Abhängigkeiten
Prozentsatz an totem Code	Umfangreduzierung, nicht erreichbaren Code von der Konvertierung ausschließen
COMP-3 Felder	BigDecimal Zuordnung für jedes numerische Feld
PIC X Feldlängen	String-Typzuordnung und Einschränkungen der Persistenzschicht
PERFORM-Graphstruktur	Zerlegung der Serviceschicht, PERFORM-Ketten werden zu Domänendienstaufrufen
DATEISTATUS-Nutzung	Entwurf des Ausnahmemodells, welche Statuscodes welchen Ausnahmetypen zugeordnet sind

Was die Konvertierung stattdessen ergeben sollte

Die Alternative zu Jobol ist ein Konvertierungsprozess, der COBOL als Spezifikation und nicht als Vorlage verwendet. Das COBOL-Programm kennt die Geschäftslogik; das Java-Programm sollte diese Logik in der Java-Sprache ausdrücken.

Das Umrechnungsprinzip: Die Absicht, nicht die Syntax, muss umgesetzt werden. COBOL IF CUST-CREDIT-SCORE < 650 MOVE 'DECLINED' TO WS-CREDIT-RESULT Es heißt: „Ein Kunde mit einer Kreditwürdigkeit unter 650 wird abgelehnt.“ Java sollte dasselbe in der Java-Sprache ausdrücken: if (customer.creditScore() < CreditThresholds.MINIMUM_SCORE) return CreditDecision.declined(...). Nicht if (CUST_CREDIT_SCORE < 650) { WS_CREDIT_RESULT = "DECLINED"; }.

Der praktische Konvertierungs-Workflow, der idiomatischen Java-Code erzeugt:

Schritt 1: Strukturanalyse des COBOL-Quellcodes, Abhängigkeitsgraph, Inventar der Geschäftslogik, Wiederherstellung des Datenmodells, Identifizierung von ungenutztem Code. Dieser Schritt erzeugt die Spezifikation. Vor Abschluss dieses Schrittes erfolgt keine Konvertierung.

Schritt 2: Domänenmodellentwurf. Identifizieren Sie die Geschäftsobjekte (Kunde, Konto, Transaktion, Police), mit denen die COBOL-Programme arbeiten. Diese werden zu Java-Domänenklassen. Die WORKING-STORAGE-Variablen, die den Zustand der Entitäten repräsentieren, werden zu Instanzfeldern der entsprechenden Domänenklasse.

Schritt 3: Entwurf der Serviceschicht. Identifizieren Sie die Geschäftsprozesse (Kreditprüfung, Zahlungsabwicklung, Kontostandsberechnung), die durch die COBOL-Abschnitte und -Abschnitte implementiert werden. Diese werden zu Java-Servicemethoden der entsprechenden Domänen-Serviceklasse. Die PERFORM-Kette, die die Abschnitte sequenziert, bildet die Orchestrierungslogik des Services.

Schritt 4: Automatisierte Konvertierung als Entwurfsgenerator: Verwenden Sie das Konvertierungstool, um für jedes Programm einen Java-Startentwurf zu erstellen, der auf dem in den Schritten 2 und 3 entworfenen Domänenmodell basiert. Überprüfen Sie den Entwurf anhand des Geschäftslogik-Inventars, um sicherzustellen, dass jeder Entscheidungszweig repräsentiert ist.

Schritt 5: Systematisches Refactoring gegen die Jobol-Muster, Anwendung der sechs Anti-Pattern-Korrekturen: Ersetzen von statischem Zustand durch Instanzzustand, Verteilung statischer Methoden auf Domänenklassen, Ersetzen von Statuscodes durch Ausnahmen, Ersetzen von double und BigDecimalErsetzen Sie Arrays fester Länge durch String, monolithische Klassen in Dienste mit jeweils einer Verantwortung zerlegen.

Schritt 6: Verhaltensäquivalenztest. Führen Sie den refaktorierten Java-Code anhand des aus der COBOL-Analyse generierten Charakterisierungstestkorpus aus. Jede EVALUATE-Bedingung und jeder IF-Zweig sollte mindestens einen Testfall enthalten, der diese Bedingung ausführt und die Äquivalenz mit der COBOL-Ausgabe verifiziert.

Wie SMART TS XL Verhindert Jobol an der Quelle

Die strukturelle Analyse, die Voraussetzung für die Vermeidung von Jobol ist – der Abhängigkeitsgraph, das Inventar der Geschäftslogik, die Identifizierung von totem Code und die Wiederherstellung des Datenmodells –, ist genau das, was SMART TS XLDie Analyse des COBOL-Quellcodes erfolgt vor dem Ausführen eines Konvertierungstools.

SMART TS XL statische Code-Analyse Es listet jede EVALUATE-Bedingung, jeden IF-Zweig, jede COMPUTE-Formel und jede PERFORM-Beziehung im COBOL-Quellcode auf – die vollständige Geschäftslogik, die der refaktorierte Java-Code exakt abbilden muss. Wenn das Konvertierungstool Jobol erzeugt, dient diese Geschäftslogik als Spezifikation, anhand derer die Refaktorisierung validiert wird: Jede Bedingung der Liste muss im Java-Code, in der entsprechenden Domänenklasse und gemäß der Java-Sprache ausgedrückt sein.

Die Abbildung der Anwendungsabhängigkeiten erzeugt den PERFORM-Graphen und den Programmaufrufgraphen, die die Struktur der Java-Serviceschicht bestimmen. Programme, die sich gegenseitig aufrufen, gehören häufig zum selben abgegrenzten Kontext. Programme, die von vielen anderen aufgerufen werden, sind die gemeinsam genutzten Dienste, die sorgfältig entworfen werden müssen, um alle ihre Nutzer in der Java-Architektur zu unterstützen. Der Abhängigkeitsgraph ist die Eingabe für den Entwurfsschritt der Serviceschicht und wandelt die implizite Kopplungsstruktur von COBOL in die explizite Abhängigkeitsinjektionsstruktur von Java um.

Die Analyse zur Legacy-Modernisierung identifiziert toten Code, Absätze und Abschnitte, die in der Produktionsumgebung nie erreicht werden und daher vollständig vom Konvertierungsprozess ausgeschlossen werden sollten. Die Konvertierung von totem COBOL-Code in toten Jobol-Code und das anschließende Refactoring dieses toten Jobol-Codes sind unnötige Ressourcen, die durch die Identifizierung des toten Codes vor Beginn der Konvertierung eingespart werden.

Die Auswirkungsanalyse validiert die Refactoring-Reihenfolge: Ändert sich die Schnittstelle eines COBOL-Programms während des Refactorings von Jobol zu idiomatischem Java, identifiziert die Auswirkungsanalyse alle anderen Programme, deren Java-Äquivalent ebenfalls aktualisiert werden muss, um die Konsistenz mit der geänderten Schnittstelle zu gewährleisten. Das Refactoring in Abhängigkeitsreihenfolge, beginnend mit den wenigsten Abhängigkeiten, minimiert den Koordinationsaufwand in jedem Schritt.

Konverter übersetzen Syntax. Modernisierung transformiert Bedeutung.

Automatisierte COBOL-zu-Java-Konverter sind schneller als manuelles Umschreiben. Sie sind jedoch für ein anderes Ziel optimiert: syntaktische Entsprechung statt semantischer Äquivalenz im Idiom der Zielsprache. Jobol ist das Ergebnis syntaktischer Entsprechung, wenn Quellsprache (COBOL) und Zielsprache (Java) grundlegend unterschiedliche Strukturmodelle aufweisen.

Die Organisationen, die Jobol meiden, sind nicht diejenigen, die bessere Konverter verwenden. Sie sind diejenigen, die den Konverter eher als Entwurfsgenerator denn als fertiges Produkt betrachten, vor Beginn der Konvertierung in Strukturanalysen investieren, das Java-Domänenmodell vor der Ausführung des Konverters entwerfen und die Ausgabe des Konverters systematisch refaktorisieren, wobei das Geschäftslogikinventar als Validierungsspezifikation dient.

Jobol lässt sich vermeiden. Die Kosten dafür sind die notwendigen Strukturanalysen und die Domänenmodellierung, die jeder Umstellung vorausgehen sollten. Die Kosten dafür sind ein Java-System, dessen Wartung COBOL-Kenntnisse erfordert. Dadurch wird der erwartete Nutzen der Modernisierung – die Möglichkeit, das System mit Java-Entwicklern zu warten – nicht realisiert.

Die Intention muss verändert werden, nicht die Syntax. Genau darin liegt der ganze Wert der Modernisierung.