Quale lingua faresti porte programmi COBOL e perché?

Question

Quando si seleziona una lingua per programmi COBOL porta dalla quale lingua si sceglierebbe e perché? Non sto cercando per la risposta "perché mi è familiare con il linguaggio X".

Cerco caratteristiche in un linguaggio che mappano bene il disegno del COBOL.

Aggiornamento:. I programmi dovrebbero eseguire il gammit alle utenze, l'elaborazione dei dati, schermi, ecc

Answer 1

Vorrei porta loro di ... ehm ... COBOL. Sì è quello. COBOL.

Siamo spiacenti, non ha potuto resistere.

Scherzi a parte, ci sono compilatori COBOL per le piattaforme attuali là fuori e, a meno che non sappiamo un po 'di più sul perché il codice ha per essere portato, potremmo non essere in grado di aiutare.

è la piattaforma su cui viene eseguito obsoleto? È la gestione solo spingendo per una soluzione più 'moderno'? Stai avendo a spostare roba da System z a Windows (ugh!)?

COBOL (nella sua forma più pura, non quella OO-COBOL errore) è principalmente un semplice linguaggio procedurale (ReportWriter benché) così si tradurrà in una qualsiasi delle altre languges procedurali abbastanza bene:

• C.
• C ++ senza classi
• Java, anche se non è possibile evitare le classi a meno che non si dispone di una grande honkin' Singleton.
• Pascal (scambiare una lingua 'morto' per un altro).
• anche Python, Perl ed altri può essere fatto funzionare.

Answer 2

Bene, si dovrebbe considerare che cosa ingressi programmi COBOL di solito ottengono.

COBOL è stato progettato per elaborare grandi quantità di testo formattato larghezza fissa come input, output nello stesso modo. Questo suona più come un processo di ETL per me più di qualsiasi altra cosa.

Quindi, non voglio programmi COBOL porta a semplicemente un'altra lingua; Mi piacerebbe portarlo a idonee tecnologie ETL come ad esempio SQL Server Integration Services (SSIS) o almeno la sua DTS predeccesor - SQL Data Transformation Services. SSIS implica usando VB.NET (almeno in SQL Server 2005), ma questo non dovrebbe essere un problema.

Answer 3

Non so molto COBOL, ma non credo che ci sia un linguaggio attuale, che è un superset rettilineo di esso (quindi, non è facile per mappare direttamente COBOL alla lingua). Vedo diversi problemi:

1. Il supporto incorporato per l'aritmetica decimale -. Questo esclude qualsiasi lingua moderna senza l'overloading degli operatori

2. Migliorato il supporto per i record strutturati -. Si potrebbe usare combo struct / union come in C, ma penso che sarebbe identificatori molto lunga a volte (almeno per i programmi che ho visto)

3. dichiarazioni Goto -. Senza di essa, si sarebbe potuto analizzare completamente la logica del programma quando riscriverlo

Ci possono essere altre caratteristiche che non sono facili da mappare.

Answer 4

Mi piacerebbe eseguo personalmente questa decisione in base al disegno previsto del programma, piuttosto che la sua attuale implementazione. Se si desidera una porta diritto-out linea-per-line, anche se, probabilmente dire C / C ++.

Answer 5

Forse invece di subito guardando un nuovo linguaggio che si potrebbe prendere in considerazione la transizione un po 'del vostro codice per un quadro contemporanea come .Net - si potrebbe trovare che una buona soluzione intermediatery, fino a quando si è pronti ad andare fino in fondo.

Ci sono alcuni compilatori Cobol per .NET disponibili, come di Fujitsu NetCOBOL .

Answer 6

Una volta ero coinvolto porting alcune cose COBOL a C (1989 o giù di lì.) Il COBOL in questione era il codice per il monitoraggio allarmi antifurto, allarmi antincendio, ecc E 'stato il tipo di programma che è adatto ad una più in tempo reale tipo di ambiente. Polling questi dispositivi di campo gazillion cliente tante volte al minuto, ecc Guardando "per le caratteristiche in una lingua che mappano bene il disegno del COBOL" ignora il fatto che ci sono un sacco di programmi COBOL là fuori che ignorano il design del COBOL.

Answer 7

Manterrei nucleo COBOL ma espandere attorno ai bordi.

Microfocus fornire uno strumento chiamato Enterprise Server che permette COBOL di interagire con i servizi web.

Se si dispone di un programma COBOL A e un altro programma COBOL B e A chiama B tramite la sezione di interfaccia, lo strumento consente di esporre sezione Interfaccia di B come un servizio web.

Per il programma A, è quindi generare un proxy client e A possono ora chiamare B tramite un servizio web.

Naturalmente, perché B ha ora un servizio web di qualsiasi altro tipo di programma (a riga di comando, l'applicazione di Windows, Java, ASP, ecc) possono ora anche chiamare.

Inoltre, hanno un prodotto chiamato COBOL.NET che viene eseguito all'interno di Visual Studio e traduce COBOL a MSIL. Ciò significa che è possibile collegare a qualsiasi componente .NET.

Quindi, l'approccio è quello di mantenere il nucleo COBOL, ma l'interfaccia tramite servizi Web e di fare nuovi sviluppi in qualsiasi lingua CLR compatibile (C #, VB ecc)

Answer 8

• devo dire che non dovrebbe COBOL porta.
  • Se vuoi dire riscrivere , allora sì, scegliere una lingua. Vorrei suggerire un'interfaccia web, Java o .Net, di riscrivere in.
  • Se il codice deve essere eseguito esattamente come funziona la società, qualsiasi conversione "porting" sarà solo fare del male.
• Se è necessario modificare le piattaforme per qualche motivo, è possibile utilizzare COBOL su un'altra piattaforma.
• Che cosa ha funzionato meglio nella mia esperienza è quello di provare la separazione di componenti o servizi gli uni dagli altri, e sia la conversione di piccoli pezzi singolarmente o semplicemente scrivere nuovo codice in una lingua preferita, mantenendo il COBOL esecuzione in back-end.

Answer 9

In primo luogo si deve, come il motivo per cui COBOL deve essere portato? COBOL è un momento potente linguaggio che molto probabilmente ha ancora più righe di codice in esecuzione libro paga, contabilità, ecc nella produzione di qualsiasi altra lingua onorato.

Il porto meno doloroso sarebbe Synergy DBL. Si tratta di un aggiornamento di stile VM altamente portatile di DIBOL (Digital Business Oriented Language).

http://www.synergex.com/synergy-dbl/

DIBOL utilizzato tutti i pezzi buoni da quella di base, FORTRAN e COBOL lasciando fuori la maggior parte del cattivo.

Se il link riportato sopra si vedrà che hanno GUI, .NET e altri strumenti di miglioramento. Basta essere certi c'è una macchina virtuale per qualsiasi sistema operativo di destinazione verrà eseguita su.

IBM Mainframe COBOL fare uso pesante di CICS, TCAM, IDMS, ecc sarà una porta davvero difficile a qualsiasi altra cosa.

OpenVMS COBOL facendo uso di DECForms o addirittura FMS sarà una porta difficile senza un pacchetto gestione dello schermo. Molto vecchio COBOL da quei negozi farà uso copioso di servizi di sistema ed eseguire in tempo routine di libreria fornite dal sistema operativo, che non saranno disponibili sulla maggior parte delle altre piattaforme. Avrete anche di leggere su Logicals e capire come implementare qualcosa di un po-sorta-vicino-a sufficienza sul vostro obiettivo.

Cosa si può trovare con la maggior parte dei mainframe e mid-range COBOL è che non solo porting COBOL. Ci saranno un sacco di servizi di sistema che COBOL vecchio fatto uso.