Esperienza di migrazione legacy Cobol/PL1 in Java

Question

ORIGINALE Q: Mi chiedo se qualcuno abbia avuto esperienza di migrazione di un grande codebase Cobol/PL1 in Java?

Quanto è stato automatizzato il processo e quanto è stato mantenibile l'output?

Come ha funzionato il passaggio da transazionale a OO?

Sarebbe gradita qualsiasi lezione appresa lungo il percorso o risorse/white paper che potrebbero essere di beneficio.

---

EDIT 7/7: Certamente l'approccio NACA è interessante, la possibilità di continuare a fare le modifiche BAU al codice COBOL fino al punto di rilasciare la versione di Java ha il merito per qualsiasi organizzazione.

L'argomento per Java procedurale nello stesso layout del COBOL per dare ai codificatori un senso di comodità mentre familiarizza con il linguaggio Java è un argomento valido per una grande organizzazione con una base di codice estesa. Come @Didier sottolinea il risparmio annuale di $ 3mil dà spazio a generose imbottiture su eventuali modifiche BAU andando avanti a rifattorizzare il codice su base continuativa. Come dice lui, se ti interessa della tua gente, trovi un modo per renderli felici mentre li sfidi gradualmente.

Il problema come la vedo io con il suggerimento da @duffymo a

meglio per cercare di capire veramente il problema alla radice e ri-esprimerla come un sistema orientato agli oggetti

è che se si dispone di eventuali modifiche BAU in corso quindi durante la durata del progetto LONG di codificare il nuovo sistema OO si finisce codificare & modifiche di test sul doppio. Questo è uno dei principali vantaggi dell'approccio NACA. Ho avuto un'esperienza di migrazione delle applicazioni Client-Server in un'implementazione web e questo è stato uno dei principali problemi che abbiamo riscontrato, cambiando costantemente i requisiti a causa delle modifiche BAU. Ha reso la pianificazione PM & una vera sfida.

Grazie a @hhafez chi è l'esperienza è ben messo come "simile ma leggermente diverso" e ha avuto un'esperienza ragionevolmente soddisfacente di una migrazione automatica del codice da Ada a Java.

Grazie a @Didier per aver contribuito, sto ancora studiando il tuo approccio e se avessi qualche Q ti farò una linea.

Answer 1

Aggiornamento 6/25: Un amico ha appena eseguito il convertitore da NACA Cobol a Java. Sembra abbastanza interessante, è stato usato per tradurre 4 m linee di Cobol con precisione al 100%. Ecco lo NACA open source project page. Gli altri convertitori che ho visto erano proprietari e i materiali mancavano in modo evidente di storie di successo e codice di esempio dettagliato. NACA merita una lunga occhiata.

Aggiornamento 7/4: @Ira Baxter riferisce che l'output Java ha un aspetto molto Cobolesco, che è assolutamente necessario. Per me, questo è il risultato naturale della traduzione automatica. Dubito che troveremo mai un traduttore molto migliore. Questo forse sostiene un approccio di riscrittura graduale.

Aggiornamento 2/7/11: @spgennard sottolinea che ci sono alcuni compilatori Cobol sulla JVM, ad esempio Veryant di isCobol Evolve. Questi potrebbero essere usati per facilitare gradualmente la transizione della base di codice, anche se penso che l'OP fosse più interessato alla conversione automatica della sorgente.

---

Sarei molto cauto in merito. (Lavoravo per un'azienda che automaticamente corretti i programmi Cobol e PL/I per Y2K, e ha fatto il compilatore front-end che ha convertito molti dialetti di Cobol nella nostra forma analitica intermedia e anche un generatore di codice.) Il mio senso è che si finirebbe con una base di codice Java che sarebbe ancora inelegante e insoddisfacente con cui lavorare. È possibile che si verifichino problemi di prestazioni, dipendenze da librerie fornite dal fornitore, codice generato con errori e così via. Sicuramente sosterrai un'enorme fattura di prova.

Partire da zero con un nuovo design orientato agli oggetti può essere l'approccio giusto, ma è anche necessario considerare attentamente i decenni di conoscenza archiviata rappresentata dal codice di base. Spesso ci sono molte sottigliezze che il tuo nuovo codice potrebbe perdere. D'altra parte, se hai difficoltà a trovare personale per mantenere il sistema legacy, potresti non avere scelta.

Un approccio graduale sarebbe il primo aggiornamento a Cobol 97. Questo aggiunge l'orientamento all'oggetto, quindi è possibile riscrivere e refactare i sottosistemi singolarmente quando si aggiungono nuove funzionalità. Oppure puoi sostituire singoli sottosistemi con Java appena scritto.

A volte sarete in grado di sostituire i componenti con software standard: abbiamo aiutato una compagnia assicurativa molto grande che aveva ancora 2 milioni di linee di codice in un linguaggio legacy creato negli anni '50. Abbiamo convertito metà di questo in un linguaggio legacy conforme allo standard Y2K, e hanno sostituito l'altra metà con un moderno sistema di paghe che hanno acquistato da un fornitore esterno.

Answer 2

La mia esperienza è simile ma leggermente diversa. Abbiamo una grande e vecchia base di codice in Ada (0.5Mloc oltre 15 + anni) che è stata recentemente convertita in Java. È stato esternalizzato a una società che ha fornito una combinazione di conversione automatica/manuale. Hanno anche fatto dei test per verificare che i sistemi Ada e Java si comportassero allo stesso modo.

Alcune parti di esso in cui scritti in Ada 95 (vale a dire ha avuto la possibilità di programmazione orientata agli oggetti), ma la maggior parte di esso non era

Ora sì che il codice non è fino agli stessi standard di codice scritto in Java nel il primo posto, ma lo usiamo da allora con successo (18 mesi) senza grossi problemi. Il principale vantaggio che abbiamo ottenuto è stato che ora possiamo trovare altri sviluppatori per mantenere la nostra base di codice con le competenze per produrre codice gestibile. (Nessuno può svilupparsi in Ada ma come qualsiasi altra lingua se non si ha esperienza in esso si può finire con codice non mantenibile)

Answer 3

Ho appena visto la pagina e i documenti NACA. Dal loro documentazione:

"Java generato utilizza una sintassi Cobol simile E 'il più vicino possibile dalla sintassi originale Cobol, entro naturalmente i limiti del linguaggio Java codice generato non sembra nativo classica.. java e non è orientato agli oggetti dal punto di vista dell'applicazione Questa è una scelta vincente per design, per consentire una migrazione senza problemi degli sviluppatori Cobol nell'ambiente Java. L'obiettivo è quello di mantenere la conoscenza del business nelle mani delle persone che hanno scritto programmi originali Cobol ".

Non ho visto un esempio, ma la citazione dà un forte sapore del risultato. Il suo COBOL codificato in Java.

È sempre possibile creare un "Traduttore" da una lingua a un'altra, tramite semplicemente codificando un interprete nella lingua di destinazione. Questo è IMHO un assolutamente terribile per tradurre un langauge quando finisci con il il peggiore dei due mondi: non hai il valore della nuova lingua, e devi ancora avere conoscenza di quello vecchio per mantenere il risultato vivo. (Non mi stupisce che questa cosa si chiami "Transcoder", non avrei mai sentito questo termine prima di ).

L'argomento per questo stunt è quello di scaricare i costi del mainframe. Dov'è la prova che i costi di lavoro sul programma convertito non sommergono i risparmi? Ho il sospetto che le operazioni che le persone hanno ridotto il loro costo spodestando il mainframe e che non possano importare di meno di le attività di manutenzione diventate più costose. Mentre questo può essere razionale per le operazioni ragazzi, è una scelta stupida per l'orgnizzazione nel suo complesso.

Il cielo aiuta le persone che sono vittime di questo strumento.

EDIT Maggio 2010: ho trovato un esempio dell'output di NACA; uno dei loro testicoli . Questo è assolutamente magnifico JOBOL. È una buona cosa che sono mantenendo i loro programmatori COBOL e non vogliono assumere programmatori Java. Mentre leggi questo, assicurati di ricordare codice Java.

/* 
* 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("", VX10); 
    assertIfDifferent("", VX10); 

    move(VX10, V9Comp010); 
    long l = V9Comp010.getLong(); 
    assertIfFalse(l ==L); 

    multiply(1000, V9Comp010).to(V9Comp014V4); 
    assertIfFalse(000L == V9Comp014V4.getLong()); 

    String cs = V9Comp010.toString(); 
    cs = V9Comp014V4.toString(); 
    assertIfDifferent("000.0000", V9Comp014V4); 

    inc(V9Comp010); 
    assertIfFalse(9876543211L == V9Comp010.getLong()); 

    CESM.returnTrans(); 
    } 

Bambini: questo è fatto solo da professionisti. Non provarlo a casa.

Answer 4

Dal punto di vista dell'elusione del rischio, l'approccio NACA ha assolutamente senso. Riutilizzare i loro strumenti potrebbe non farlo. Hanno usato lo sviluppo degli strumenti per far crescere rapidamente le persone in java e linux.

Il risultato della conversione NACA non sarà abbastanza buono, o addirittura OO, e rende difficile assumere nuove persone. Ma è testabile, può essere refactored e puoi inserire traduttori migliori.

[modifica] Ira, non sembri molto attento al rischio.

L'invio dei programmatori cobol a un corso Java non consente di scrivere codice orientato agli oggetti utilizzabile. Ciò richiede alcuni anni. Durante questo periodo, la loro produttività sarà molto bassa e in pratica puoi buttare via tutto il codice che scrivono il primo anno. Inoltre, perderai il 10-20% dei tuoi programmatori, che non sono disposti o in grado di effettuare la transizione. Molte persone non amano tornare allo stato di principiante, e influenzerà l'ordine gerarchico, dal momento che alcuni programmatori prendono il nuovo linguaggio molto più velocemente di altri.

L'approccio NACA consente all'azienda di continuare a lavorare e non esercita alcuna pressione sull'organizzazione. La pianificazione temporale per la conversione è indipendente. Avere un traduttore separato, in java, scritto da esperti OO, consente una graduale esposizione a java per la vecchia squadra. La scrittura dei casi di test aumenta la conoscenza del dominio nel nuovo team di java.

Il vero oo sistema è il traduttore, e questo è il posto giusto per collegare traduttori migliori. Facilitarlo facilmente e non è necessario toccare il codice generato.Se il codice generato è abbastanza brutto, questo è ciò che accadrà automaticamente: :) ​​

• i vecchi programmatori cambieranno l'ingresso cobol;
• i nuovi java cambieranno il traduttore.

[eseguire il traduttore una volta] è una strategia sbagliata. Non farlo. E se è necessario modificare il codice generato, mantenere un mapping indietro. Questo può essere automatizzato. E dovrebbe essere. È molto più facile fare questo genere di cose in un'immagine Smalltalk, ma puoi farlo con i file. Ci sono persone con molta esperienza che mantengono punti di vista diversi sullo stesso artefatto: i progettisti di chip vengono in mente.

Il traduttore deve essere strumentato, quindi è possibile creare i conteggi giornalieri di ad es.

• componenti di input cobol;
• OO componenti di input java;
• componenti di output in stile cobol;
• Componenti di uscita stile OO.

Si potrebbe desiderare di leggere: Peter van den Hamer & Kees Lepoeter (1996) Gestione dei dati di progettazione: Le cinque dimensioni di CAD Frameworks, gestione della configurazione e gestione dei dati, Proceedings of the IEEE, vol. 84, n. 1, gennaio 1996

[spostamento di piattaforme Cobol] Lo spostamento da Cobol sul mainframe a Cobol su Windows/Linux avrebbe potuto essere una strategia praticabile per il team NACA, ma la domanda riguardava il passaggio a Java. Se l'obiettivo a lungo termine è quello di avere un moderno sistema OO, e di arrivarci con il minimo rischio operativo possibile, l'approccio NACA è solido. È solo il primo passo, però. Seguirà un sacco di refactoring.

Answer 5

Era chiaramente il nostro intento di ottenere il codice java iniziale che era molto vicino al cobol originale al fine di facilitare la migrazione delle persone: trovano la buona vecchia app che hanno scritto in cobol nella stessa identica struttura.

uno dei nostri obiettivi più importanti era quello di mantenere gli sviluppatori iniziali a bordo: questo è il modo in cui abbiamo trovato per raggiungerlo. Quando l'applicazione viene migrata su Java, queste persone possono iniziare a renderlo più OO mentre lo sviluppano/refactoring ulteriormente.

Se non ti interessa migrare le persone, puoi utilizzare un'altra strategia.

Questa conversione 1-a-1 anche fatto al 100% di conversione automatizzata semplice & più veloce: il bene conseguenza è che abbiamo fatto i nostri risparmi ricorrenti (3 milioni di euro/anno) molto più veloce: stimiamo 12-18 mesi. Quei primi risparmi possono chiaramente essere reinvestiti in OO refactoring

esitate a contattarmi: didier.durand@publicitas.com o mediaandtech@gmail.com

Didier

Answer 6

State parlando di reengineering. La cosa buona è che molte persone in tutto il mondo cercano di farlo. La cosa brutta è che ci sono molti problemi riguardanti la reingegnerizzazione delle applicazioni legacy: partendo da fonti mancanti e fino a complessi algoritmi dalla costruzione del compilatore e dai campi della teoria dei grafi.

L'idea della traduzione automatica è molto popolare, fino a quando non proverai a convertire qualcosa. Di solito il risultato è terribile e non mantenibile. È più non gestibile dell'applicazione originale complicata. Dal mio punto di vista, ogni strumento che consente la traduzione automatica da legacy a linguaggio moderno è molto orientato al marketing: dice esattamente ciò che le persone vogliono sentire "traduci la tua applicazione da ... a Java una volta, e dimentica!", Di te comprando un contratto, e poi capisci che molto strettamente dipende dallo strumento (perché non puoi apportare alcuna modifica alla tua applicazione senza di essa!).

L'approccio alternativo è "comprensione": lo strumento, che consente una comprensione molto dettagliata della vostra applicazione legacy. E puoi usarlo per la manutenzione, o per la documentazione o per reinventare su una nuova piattaforma.

Conosco un po 'la storia dello Modernization Workbench prima che Microfocus l'acquistasse l'anno scorso e trasferisse lo sviluppo in un altro paese. C'era un gran numero di strumenti di analisi complessi e il numero di lingue di destinazione supportate (incluso Java). Ma nessun client ha realmente utilizzato la generazione automatica del codice, quindi lo sviluppo della parte generazionale è stato bloccato. Per quanto ne so, il supporto per PL/I è stato implementato principalmente, ma non è mai stato completato. Ma puoi ancora provare, potrebbe essere questo quello che stai cercando.

Answer 7

Sono sorpreso che nessuno abbia menzionato il DMS Software Reengineering Toolkit di Semantic Design. Ho esaminato la conversione COBOL in passato. Allora stavo lavorando alla "programmazione automatica". Prima di scrivere un traduttore, ho cercato un sacco di precedenti sforzi e prodotti in quell'area. Lo strumento GLR di Semantic Designs è stato il migliore del gruppo.

Questo è stato molti anni fa. A quel tempo, lo strumento traduceva COBOL in un linguaggio moderno, lo refactored, stampato piuttosto, ecc. Ecco il link ad esso ora.

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

Sono ancora in giro. Hanno ampliato lo strumento. È più generale. Potrebbe aiutare le persone a fare conversioni automatiche o personalizzare uno strumento di conversione. È progettato per essere espandibile e modificabile in modo simile a quello che Stephan ha sottolineato. Grazie a Cyrus anche per aver menzionato SoftwareMining. Guarderò anche a loro se mi imbatterò in una migrazione COBOL in futuro.