Il 70% dei programmi / applicazioni aziendali / qualcosa basato su COBOL? [chiuso]

La pagina wiki COBOL cita la citazione di Gartner, ma non c'è una fonte fornita da Gartner. È tutto attraverso la rete. 80% delle imprese, 200 miliardi di linee di codice, 5 miliardi di nuove linee di codice ogni anno. Alcuni posti, i numeri variano un po '. Tuttavia, un numero è quasi sempre mancante da quella citazione Gartner sulla pagina wiki COBOL, e il numero mancante è l'anno. 1997. Supponiamo che la citazione fosse vera, nel 1997.

Ho lavorato in COBOL per 20 anni e negli ultimi 13 anni ho assistito alla scomparsa dello sviluppo di COBOL.

Soluzioni ERP? L'ultimo a sapere che aveva almeno un po 'di COBOL nel prodotto era PeopleSoft, quando ho parlato con i rappresentanti di PeopleSoft in una conferenza IT del 2004. All'epoca lavoravo per la UW, e ho parlato con letteralmente dozzine di persone, forse verso l'alto di 100, dalle università di tutto il paese. Una storia molto comune è stata ripetuta. "Abbiamo sostituito la nostra soluzione ERP homegrown, scritta in COBOL, con" PeopleSoft, Oracle, SAP, SunGard. Approfondire i collegamenti di carriera di quelle aziende e guardare le posizioni IT. Vedi se c'è qualche menzione di COBOL, DB2, CICS, ecc.

Sanità? Bene, ho lavorato per GE Healthcare per 3 anni e sono stati tra gli ultimi fornitori di software clinici ospedalieri a scrivere in COBOL. 3 grandi licenziamenti in 3+ anni, un ufficio che è passato da 600 dipendenti a meno di 300 dipendenti, clienti che si convertivano in Epic o Cerner. Non c'è un futuro molto luminoso per COBOL lì. Né Epic né Cerner scrivono in COBOL. Dai un'occhiata alle loro pagine sulla carriera. McKesson sembra essere ancora scritto in COBOL, ma vedo un certo numero di ospedali che si convertono anche da loro.

Il governo statale e federale potrebbe finire nell'ultimo bastione di COBOL, ma alcuni di questi progetti sono andati via. Completamente sostituito con .NET o Java.

A 44 anni, sono uno dei COBOLer più giovani che conosca. Oh, ci sono 5 o 6, so chi è più giovane di me, ma i 100 o più altri che conosco sono probabilmente in media 10-15 anni più di me.

IBM 390 e zSeries, HP NonStop, Unisys 2200 e Unisys MCP sono le grandi scatole di ferro là fuori che eseguono COBOL. Ognuno di essi supporta lo sviluppo Java. Da quanto ho letto e conosciuto Java su grande ferro, che è per lo più limitato a HP NonStop, se è fatto proprio allora Java può sostituire COBOL nel tempo.

Ci sono stati degli sforzi, che conosco o ho lavorato, dal 1994 per sostituire gli schermi verdi di mainframe goffe con i front-end della GUI scritti in VB, .NET o Java.

Molti COBOLer con cui parlo, certi del futuro di COBOL, sono senza lavoro, come me, e non stanno trovando lavoro. Il miglior scatto che ho è un concerto di stato in cui ci sono probabilmente più di un paio di persone in pochi anni di pensione. Supponendo di entrare, mi aspetto che nei prossimi due anni il mio ruolo si evolverà in come pulire, efficientemente e senza interrompere l'attività di gestione di un'iniezione letale, in senso figurato, a COBOL attraverso la sostituzione passo dopo passo.

Finalmente, torna a Gartner. Fanno pagare per tutto ciò che pubblicano, e non è economico. Ma avventurati su Gartner.com, crea un account gratuito, vai alla scheda Ricerca e cerca la parola chiave COBOL. Non riceverai l'intero articolo, ma riceverai un riassunto e un frammento. Leggendo e analizzando il lavoro di Gartner, penso che sia molto chiaro che stanno segnalando la morte di COBOL.

A seconda di come si definisce il 100%, quel numero potrebbe essere corretto. Ad esempio, potrebbe benissimo essere che il 70% dei programmi scritti per banche e istituti finanziari fino al 2010 sia basato su COBOL. Non sarei sorpreso.

Ma non penso che sia un'affermazione equa dire che da tutto il software nel mondo , il 70% verrebbe scritto in COBOL. Francamente, non so se puoi misurarlo.

il gruppo Gartner ha riferito che l'80% delle attività mondiali ha funzionato con COBOL con oltre 200 miliardi di linee di codice esistenti e con una stima di 5 miliardi di righe di nuovo codice all'anno. La fonte è: COBOL-1 .

Non ho idea di come contano questi numeri. Ho lavorato in diverse aziende in cui nessuno in realtà ha provato a contare tutte le righe di codice in un negozio con precisione, anche quando è stato usato come una misura di complessità. Quindi come hanno trovato questi numeri?

COBOL è vivo e vegeto. Non è vero dire che ci sono zero progetti che iniziano a usare COBOL. Ricorda che molti progetti aziendali sono interdipendenti. A meno che non ci sia un motivo per estendere un progetto in una lingua diversa, si utilizza l'architettura e il software originali. Ricorda che la maggior parte di questi sistemi è grande e riscriverli in una lingua diversa è rischioso, costoso e di solito aggiunge poco o nessun valore al business.

Ci sono molte risorse sulla rete che ci dicono che COBOL è vivo e vegeto.

Penso che queste cifre risalgano all'incirca verso il 1997, quando il "problema" Y2K era l'argomento scottante nell'IT (in particolare i venditori per fare un soldo veloce!). Al momento ci sono stati alcuni seri tentativi di scoprire quanto codice COBOL / C / C ++ / Java / VB ecc. Fosse effettivamente in esecuzione per capire quanto lavoro fosse necessario. È stato uno shock per le persone quanto il codice base del mondo fosse COBOL.

Mi aspetto che questa cifra sia molto meno ora, in parte a causa del lungo lento declino del COBOL, ma soprattutto perché da allora in poi c'è molto codice scritto in altre lingue. Basti pensare, php, esisteva a malapena nel 1997.

Prima di tutto, queste stime sono discutibili. In secondo luogo, anche supponendo che i numeri siano corretti, le stime si basano su una metrica di righe di codice (LoC). COBOL è estremamente dettagliato , quindi è necessario un codice di ordine di grandezza maggiore per ottenere la stessa cosa. Considera "Ciao mondo" in 3 lingue di programmazione:

Python:

print "Hello world!"

C:

#include <stdio.h>

int main() {
    printf("Hello world!\n");
}

COBOL:

000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. HELLOWORLD.
000300
000400*
000500 ENVIRONMENT DIVISION.
000600 CONFIGURATION SECTION.
000700 SOURCE-COMPUTER. RM-COBOL.
000800 OBJECT-COMPUTER. RM-COBOL.
000900
001000 DATA DIVISION.
001100 FILE SECTION.
001200
100000 PROCEDURE DIVISION.
100100
100200 MAIN-LOGIC SECTION.
100300 BEGIN.
100400     DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
100500     DISPLAY "Hello world!" LINE 15 POSITION 10.
100600     STOP RUN.
100700 MAIN-LOGIC-EXIT.
100800     EXIT.

In precedenza ho lavorato in una banca (di grandi dimensioni) e lì COBOL è stato utilizzato per tutte le principali logiche bancarie, con qualsiasi cosa al di fuori di quella che è stata eseguita in Java o C #. Sebbene sia impossibile per me essere sicuro delle linee precise di codice, credo che il 70% affermi di essere estremamente dubbioso, secondo la mia esperienza. È possibile che COBOL sia più dettagliato come illustrato da Vartec, ma in termini di funzionalità implementata, il software "ausiliario" di Java e C # stava gestendo molto di più.

Come esempio tipico, il codice COBOL era incaricato di creare effettivamente conti, calcolare interessi, generare dichiarazioni di base, nonché regole aziendali sulla gestione dello stato di un account (accesso / azioni valide). Ad essere onesti, non è una quantità insignificante di codice, ma rispetto a questo, il software "ausiliario" era responsabile di tutto, dalla ricezione di fax, all'individuazione di documenti, all'archiviazione / gestione dei documenti, al lavoro di routing per singoli, a diverse migliaia (purtroppo, sì) schermi per l'acquisizione dei dati e la gestione del lungo ciclo di vita di vari processi che terminano nella creazione di account, interfacce elettroniche ad altre società e servizi legali, integrazione con la piattaforma di telefonia e molte, molte altre funzioni.

Guardando da questo punto di vista, sono abbastanza sicuro che il numero sarebbe stato a favore del codice Java / C #, ma ancora una volta, non ho alcun numero difficile per eseguire il backup di questa affermazione.