Questo linguaggio è stato standardizzato dall'ANSI (American National Standards Institute) che ha provveduto ad aggiornare le specifiche almeno quattro volte (nel 1968, 1974, 1985 e 2002) fino a renderlo un linguaggio moderno che permette anche la programmazione a oggetti.
Il fatto che esista uno standard ha reso possibile per il COBOL una seconda giovinezza a partire dalla fine degli anni '80: in quel periodo infatti era praticamente l'unico linguaggio non proprietario che fosse disponibile su un'ampia gamma di piatteforme software/hardware e che possedesse tutte le caratteristiche necessarie alla realizzazione di programmi gestionali; in particolare possiede una gestione di file a indice integrata che evita la necessità di ricorrere a librerie specializzate per questo scopo. Grazie a queste caratteristiche il linguaggio ha trovato impiego anche nelle piccole e medie software house, riuscendo ad ampliare di molto la propria popolarità e la propria diffusione.
Ultimamente però anche le numerose funzionalità offerte dal COBOL non sono più in grado da sole di soddisfare tutte le esigenze degli utenti: oggi infatti anche le applicazioni gestionali necessitano di poter dialogare con altre applicazioni, di poter interfacciare diversi tipi di dispositivi, di poter leggere e scrivere documenti in diversi formati, di poter interfacciare diversi tipi di protocolli di rete, in altre parole di potersi integrare in un sistema informativo complesso. Diventa allora necessario integrare le proprie applicazioni con software specializzati sviluppati da terze parti. In questo modo però il sistema informativo tende a diventare un coacervo di tecnologie differenti, complesso, costoso, difficile da manutenere e che fa diventare ogni aggiornamento un incubo.
Questo tipo di problemi, che ovviamente non riguardano solo il COBOL e i programmatori che lo usano, è già stato individuato e affrontato prima da Sun, con la sua Java Platform, e successivamente da Microsoft con il suo framework .NET. Si può notare che non si parla più solo di linguaggi, anche se Java è conosciuto principalmente come tale, ma di ambienti in cui far girare comodamente i propri applicativi senza doversi preoccupare di mettere insieme diverse tecnologie in quanto entrambi gli ambienti sono omogenei e offrono tutte le funzionalità richieste dai moderni programmi.
L'idea appare senza dubbio allettante e si può dire che il mondo della produzione del software si stia lentamente avviando su questo tipo di soluzione. Microsoft e Sun hanno speso, e stanno ancora spendendo, somme ingenti per imporre la propria tecnologia sul mercato, ma non è da escludere che in un futuro le due soluzioni, ora antagoniste, non vengano integrate in quello che diverrebbe l'ambiente di riferimento mondiale per la programmazione.
Alla luce di queste considerazioni, l'unico modo per permettere a un linguaggio di sopravvivere è di integrarlo in almeno uno di questi ambienti o, meglio, in entrambi.
È per rispondere a questo tipo di esigenza che è stato sviluppato isCOBOL. Si tratta di un compilatore, commercializzato da Veryant
[1], che prende come input dei programmi COBOL standard e produce degli oggetti Java (con estensione .class) che implementano il programma. Per l'esecuzione naturalmente è necessario avere sulla macchina una JVM e un jar con i package di supporto runtime.
In realtà al momento attuale il processo di compilazione prevede prima una traduzione del codice da COBOL a Java e quindi una compilazione con un compilatore Java standard; questa è solo una scelta implementativa contingente e in rilasci futuri potrebbe non essere più così.
Insieme al compilatore, scritto anch'esso in Java, viene fornito un debugger a livello sorgente COBOL che permette le normali operazioni di debug comuni ai moderni strumenti di questo tipo.
Il prodotto ha alle spalle due anni di sviluppo ed è ancora in beta release, il rilascio della release 1.0 è previsto per gennaio 2006.
Anche se attualmente IsCOBOL è integrato nella piattaforma Java, in futuro è previsto che debba girare anche su piattaforma .NET; la scelta di privilegiare prima l'ambiente creato da Sun è dovuta al fatto che questa piattaforma è più matura, più stabile, supportata da un maggior numero di aziende e soprattutto gira su un maggior numero di sistemi operativi e macchine, dal telefonino al mainframe.
Dal punto di vista tecnico, isCOBOL segue l'ultimo standard dell'ANSI, pubblicato nel 2002, e ingloba le estensioni per l'interfaccia grafica inserite nell'AcuCobol. La scelta di inserire le estensioni di questo prodotto deriva dal fatto che è l'unico che ha incorporato nel linguaggio delle funzionalità per gestire l'interfaccia grafica utente e, poiché Java non prevede un'interfaccia utente a caratteri, si è reso necessario implementare da subito un sistema grafico. L'implementazione di quest'ultimo permette di usare sia le librerie AWT che quelle Swing: questa doppia possibilitè è stata inserita per poter permettere all'utente di sfruttare le notevoli potenzialità di Swing sulle applicazioni che girano in ambienti sufficientemente potenti e al contempo di poter realizzare applicazioni che girano su dispositivi con risorse limitate, come i computer palmari. Da notare che la selezione tra una libreria e l'altra avviene tramite un'opzione di runtime, e che quindi i programmi non sono influenzati dalla scelta.
Lo standard ANSI 2002 prevede la programmazione a oggetti e allora è stato fatto il possibile per rendere trasparente l'interoperabilità tra oggetti Java e oggetti COBOL; di fatto, non solo è possibile chiamare un oggetto Java dall'interno di un programma isCOBOL e viceversa, ma è anche possibile derivare un oggetto isCOBOL da un oggetto Java e viceversa: in tal modo con isCOBOL si possono fare applet, servlet, Enterprise Java Bean etc.
La gestione dei file a indice è, per default, affidata a JIsam, una libreria di oggetti scritta totalmente in Java che implementa un B+tree, compatibile con PicoIsam e simile per struttura ai gestori analoghi presenti sul mercato. Il festore dei file di isCOBOL permette però di poter dichiarare altri tipi di gestori di file, anche non scritti in Java, tra cui, per esempio, i file a indice di AcuCobol e i file di tipo C-TREE.
Per chi preferisce usare un database relazionale, isCOBOL è in grado di compilare programmi con istruzioni ESQL al proprio interno: le query sul database vengono poi realizzate utilizzando l'interfaccia JDBC, il che garantisce l'accesso a qualsiasi DB sul mercato.
Veryant mette inoltre a disposizione un'interfaccia particolare, chiamata DCI, che consente a programmi COBOL standard, che normalmente accederebbero a file a indice, di accedere al DB relazionale DBMaker.
Quando si parla di Java, non si può fare a meno di parlare di performances in quanto l'opinione comune è la JVM non brilli da questo punto di vista. In realtà non è così, le varie JVM sono solitamente molto efficienti e veloci, anche confrontate con le virtual machine usate per il COBOL. È vero però che i programmi Java impiegano un certo tempo per entrare in esecuzione e questo è dovuto al fatto che la JVM deve caricare in partenza, oltre l'interprete vero e proprio, un numero fisso di oggetti necessari per il funzionamento più gli oggetti da cui l'applicazione dipende.
Da prove fatte su Linux con la JVM di Sun risulta che un programma che non fa nulla usa carichi in ogni caso almeno 249 classi con la versione 1.4.2 e 295 classi con la versione 1.5_05.
È anche vero che i programmi Java necessitano di molta memoria e che in ambienti multiutente questa memoria non viene condivisa; gli oggetti Java infatti vengono visti dal sistema operativo come dati e quindi conservati come dati locali all'applicazione.
Dato che la maggior parte delle applicazioni COBOL è fatta per funzionare in multi utenza, isCOBOL implementa un "application server" che limita drasticamente questi problemi. In pratica sul server viene lanciata una sola istanza della JVM e ci si connette ad essa tramite un apposito programma lanciato sui client. Per ogni connessione all'application server, non viene creato un nuovo processo ma soltanto un nuovo thread con condivide con quelli presenti tutti gli oggetti caricati.
La cosa interessante è che non c'è alcuna differenza tra applicazioni stand-alone e client-server, per cui si può ottenere la ricchezza dell'interfaccia tipica delle applicazioni stand-alone in architetture client-server senza la necessità di usare tecniche di programmazione particolari.
In conclusione, nonostante l'età del linguaggio COBOL, isCOBOL è un prodotto nuovo e moderno che affronta i problemi che si pongono oggi dinanzi agli sviluppatori di software. Esiste un divertente documento che gira su Internet, intitolato 'Il Tao della programmazionè che a un certo punto dice:
- Il Tao ha dato alla luce al linguaggio macchina
- Il linguaggio macchina ha dato alla luce l'assembler.
- L'assembler ha dato alla luce al compilatore.
- Ora ci sono diecimila linguaggi.
- Ogni linguaggio il proprio scopo, per quanto umile.
- Ogni linguaggio esprime lo Yin e lo Yang del software.
- Ogni linguaggio ha il proprio posto all'interno del Tao.
- Ma non si programmi in COBOL se si può evitarlo.
Vedremo se questo nuovo prodotto contribuirà a cambiare questo punto di vista.
Discuti sul forum
Stampa
![[LM]](../../../images/skin/default/icons/lm_sm.png){kind=icon}
.
Made with GIMP
& WPP.