AMRITA (Automatic, Maintenance, Reengineering, Integrated, Technology Application) è un prodotto progettato per il mondo mainframe, tipicamente IBM COBOL/CICS/DB2 e Cobol Microfocus, con il primario obiettivo di fornire strumenti innovativi per ridurre drasticamente i tempi di manutenzione e comprensione del sistema informativo, oltre a dettagliate informazioni di assessment, indispensabili per la valutazione e riduzione del rischio.

La valutazione del rischio è supportata a livello decisionale, attraverso le informazioni di qualità estratte dal sistema a livello elementare successivamente riaggregate e a livello di analisi e sviluppo, dove le innumerevoli informazioni, disponibili con un click, vanno dalle generali relazioni fra i programmi fino all’istruzione elementare che ne sono origine.

Partendo dai soli codici sorgente, senza nessuna altra informazione aggiuntiva, attraverso progressivi processi di analisi, Amrita è in grado di mappare il sistema applicativo arrivando fino al dettaglio della singola istruzione. Tutti i moduli di Amrita utilizzano la stessa base dati generata in fase di analisi per fornire informazioni in tempo reale, dal livello generale fino al dettaglio elementare.

Questo processo di Assesment automatizzato, fornisce una completa comprensione dell’infrastruttura dell’applicazione e delle componenti di un ambiente mainframe. Attraverso questa tecnologia organizzazioni complesse potrebbero scoprire relazioni fra componenti del sistema che non si era consapevoli di avere, oggetti obsoleti non più utilizzati nell’ambiente mainframe e oggetti quali programmi, tabelle o altro di cui si ignorava l’esistenza.

Perseguendo i suoi obbiettivi principali, Amrita fornisce altresì una moderna piattaforma tecnologica in grado di supportare servizi di conversione, refactoring, rehosting, documentazione.

Il risultato dell’analisi sono informazioni organizzate e fruibili per ogni utilizzo e servizio del tipo

• Dimensionale
  Di ogni programma si danno dimensioni, commenti, istruzioni di definizione dati, procedure etc.
  Questi dati concorrono alla valorizzazione degli indici di qualità
• Qualita & Metriche
  A livello di programma, con il dettaglio fino alla singola procedure vengono calcolati indici di complessità di McCabe, Halstead, Function Point, Fan-in, Fan-out, SQUALE, dead code etc.
  Gli indici di qualità concorrono alla definizione dello stato di salute dell’applicazione o di una sua componente, per identificare i programmi critici dal punto di vista strutturale, di leggibilità del programma, di modificabilità etc
  In particolare il sistema SQUALE, orientato ai costi di remediation e non alla qualità intrinseca, con i suoi 5 parametri di qualità, fornisce lo strumento ideale per eventuali servizi in questa area.
• Violazione a regole di qualità
  A supporto del sistema di qualità SQUALE ma utilizzabile in generale, l’analisi del programma può fornire informazioni, a livello di dettaglio, delle violazioni ritenute pericolose per uno specifico parametro di qualità (per esempio MAINTENABILITY)
  Sono codificate circa 160 regole del tipo:
  R0085_AVOID_UNINITIALIZED_COPY_FIELD,
  R0094_AVOID_GOBACK_NOT_IN_MAINLINE,
  R0079_AVOID_UNUSED_PGM_FIELD etc
  R0142_AVOID_SQL_OPEN_CURSOR_INSIDE_LOOP
  Ogni violazione si riferisce a una caratteristica di qualità a cui è associato un tempo di remediation e che influenza i 5 parametri di qualità generali.
  Questo strumento può servire al management per prendere decisioni in merito al destino dell’applicazione o ai costi per una riscrittura.
• Relazioni
  A valle dell’analisi sono disponibili tutte le relazione fra gli oggetti del sistema, ovvero programmi, mappe video, tabelle, files di file system, codici di abend, etc, anche se originate da codice dinamico.
• Where-Used
  Tutti gli utilizzi dei campi di moduli copy e di tabelle vengono tracciati con indicazione se in Input o Output, in quale programma e in quale istruzione di programma.
• Codice Dinamico

Quando una istruzione, per esempio la call a un programma, non può essere risolta nell’istruzione stessa, in quanto il nome del programma è un campo, il contenuto effettivo viene ricercato seguendone le trasformazioni del campo nello stesso programma e nei programmi chiamati/chiamanti.

• Oggetto Java

L’analisi dei programmi e dei moduli copy produce un oggetto Java serializzato con tutti i metodi disponibili per conoscere nel dettaglio:

Istruzioni codificate con campi in Input/Output
Dead Code
Utilizzi campi nel programma
Paths di esecuzione
Sorgente del programma
Etc

L’oggetto Java serializzato, utilizzato dal modulo INSPECTOR può essere uno strumento nell’erogazione di servizi tecnici specifici.

Elenco i tipi di sorgenti analizzati:

• Pgm Cobol
  Sono gestiti tutti i livelli di Cobol IBM e tutte le varianti del Cobol Micro Focus
  In generale, ai fini degli obbiettivi dell’analisi, qualsiasi tipo di Cobol viene analizzato
• Copy book
  I moduli copy nel mondo Cobol solo assimilabili alle Include del C o di altri linguaggi.
  Amrita può analizzare separatamente i moduli copy o farlo durante il processo di analisi del sorgente. Vengono gestiti i copy che contengono altri copy a qualsiasi livello.
• Mappe BMS
  Nel mondo IBM mainframe lo screen layout 80X24 si definisce con dichiarazioni in linguaggio Assembler chiamate BMS
• JCL
  Job Control Language, si tratta del linguaggio standard di controllo di esecuzione dei programmi.
  Si può assimilare a Shell Script
• CICS precompiler
  Ogni istruzione Cics viene analizzata e per quelle significative vencono generate le apposite relazioni, per esempio fra il programma sorgente e il TRANSID, MAP etc
  
• SQL precompiler
  Amrita analizza nel dettaglio, codificandole, le singole istruzioni DML Sql individuando i nomi delle tabelle interessate, le colonne, il tipo di operazione e cosi via.
• SQL DDL
  Le informazioni di definizione del database, tabelle, indici etc fanno parte integrante del processo di analisi.

A fronte dell’analisi dei sorgenti con gli analizzatori specifici, il sistema viene completamente mappato fino alla singola istruzione per ottenere relazioni fra programmi, utilizzi dei dati elementari definiti in moduli copy o tabelle Sql, 

Una caratteristica importante da sottolineare è che Amrita non effettua solo l’analisi sorgenti ma è in grado di seguire le logiche elementari di trasformazione dei dati attraverso la catena di programmi chiamati/chiamanti e risolvere, quindi, istruzioni dinamiche quali call a programmi, accesso a tabelle etc.

Questo permette di avere certezza delle relazioni fra gli oggetti analizzati ed è fondamentale ai fini della manutenzione, documentazione ed, eventualmente, re-engineering.‍

Moduli di AMRITA

Amrita è completamente scritto in Java, utilizza MySQL come database e la Web Application accede al db via Web Services Rest.

• ANALYZER
  Rappresenta il motore di analisi di Amrita ed è completamente configurabile per un utilizzo semplice e intuitivo.
  Permette una analisi scalabile, progressiva, con visualizzazione in chiaro della progressione dell’analisi, del dettaglio analizzato, degli eventuali errori riscontrati, i tempi di analisi etc.
• VIEWER
  Permette di visualizzare tutte le informazioni memorizzate su database in termini di oggetti, relazioni, where used, dati di qualità, di conoscere con un click chi aggiorna una tabella, un campo, etc, con contestuale visualizzazione del sorgente nel punto
  Una funzione specifica fornisce la matrice CRUD di quali programmi fanno Create, Read, Update e Delete di tabelle.
  Questo modulo assolve alla principale necessità del processo di manutenzione, riducendo i tempi di comprensione, che per sistemi Cobol sono almeno del 50%, tramite l’individuazione degli oggetti da manutenere.
  Con pochi click si può individuare immediatamente il programma, l’istruzione o l’area di programma su cui intervenire, le tabelle e i campi di tabella interessati.
• INSPECTOR
  Questo modulo interviene a fronte del programma o istruzione individuato da VIEWER e permette di continuare l’analisi tecnica a livello di programma, chiamati e chiamanti.
  Sono disponibili funzioni per individuare i path di escuzione, verificare se variabili sono utilizzate nei path, seguire le trasformazioni del dato nel programma e nella catena di chiamati/chiamanti.
  Il tempo di analisi tecnica nei vecchi sistemi Cobol è di almeno il 20% del tempo di manutenzione totale.
• ASSESMENT
  Questo modulo, a fronte dei risultati prodotti da ANALYZER, fornisce tutti i dati di qualità aggregati per sottosistema applicativo con possibilità di visualizzazione progressiva fino al dettaglio di programma, sotto forma di grafici.
  Lo scopo di questo modulo è di fornire una fotografia aggiornata dello stato di salute del sistema per prendere decisioni in merito a eventuali refactoring, conversioni, sostituzioni di sottosistemi o semplicemente cambiare la priorità delle attività di manutenzione.

Servizi e tipologia di utilizzi

Non bisogna considerare Amrita solo come uno strumento tecnico che analizza programmi e fornisce informazioni ma anche come base per servizi che è possibile erogare on demand.

I possibili utilizzi potrebbero essere:

• Documentazione interattiva (VIEWER)
• Documentazione per programma come pagina Web o PDF (VIEWER)
• Manutenzione (VIEWER, INSPECTOR)
• Pianificazione manutenzione (VIEWER, ASSESMENT)
• Valutazione rischio (ASSESMENT)
• Servizi (sfruttando gli output di analisi)
  • Assesment
  • Refactoring
  • Re-hosting
  • Conversioni
  • Ottimizzazioni
  • Re-engineering
  • Isolamento di un sottosistema
  • Individuazione accessi diretti da un sottosistema ad un altro e sostituzione con chiamate a interfacce‍

Il Cobol in Italia e nel mondo

Sembra che la quantità di Cobol ancora attivo nel mondo sia considerevole, anche se nascosto da strati e strati di software, per interfacciarlo con le nuove tecnologie e si parla di percentuali attorno al 70%.

Se liberarsi del parco applicativo Cobol è impensabile per i costi di riscrittura di sistemi spesso scritti ad hoc cuciti su misura, d’altra parte manutenere i vecchi programmi Cobol diventa problematico per mancanza di know-how, carenza di competenze e di giovani che sicuramente preferiscono imparare nuove tecnologie invece che Cobol.

In questa ottica uno strumento come Amrita potrebbe soddisfare la necessità di conoscenza applicativa, riduzione dei tempi/costi di manutenzione e del rischio.
Oppure si potrebbe utilizzare Amrita come supporto alla sostituzione di un sottosistema, per costruire le interfacce verso i sottosistemi collegati, acquisire informazioni, etc.

Sicuramente ci sono realtà italiane con molto Cobol da gestire (come la PA, INPS etc.), tuttavia Il mercato è di tipo globale.

‍

‍