Tecniche di reverse engineering in riconversioni di sistemi main frame

Sommario 
 
 
 
E‟ opinione ormai consolidata, che la costante necessità di aggiornare o rinnovare il 
software dei sistemi informatici, sia per cambiamenti delle esigenze di lavoro, sia per la 
modernizzazione delle infrastrutture, come l‟avvento del terzo millennio, comporta un 
notevole sforzo speso a fronte di tali esigenze. Tale valore assorbe dal 40 al 75% delle 
attività svolte dal personale addetto alla programmazione. Ovviamente quando si supera 
il valore del 50% e si ritiene opportuno introdurre nuove tecnologie sia nell‟uso delle 
applicazioni, sia nel loro sviluppo, (si pensi ad esempio la programmazione a oggetti ed 
il suo impiego nelle piattaforme di “networking”), le “Web technologies”, diventa 
abbastanza naturale pensare di sostituire il vecchio software con un nuovo software a 
costo di reingegnerizzare l‟applicazione. 
Prima che il processo di reingegnerizzazione possa iniziare è necessario fare un 
inventario delle specifiche e la documentazione deve essere aggiornata allo stato 
dell‟applicazione in esercizio. Questo stato di cose, in generale, è appesantito dal fatto 
che le persone che progettano un sistema informatico sono normalmente diverse da 
quelle che dovranno provvedere al suo mantenimento. 
In questo contesto il Reverse Engineering assume un‟importanza fondamentale, perchè 
agevola la comprensione del sistema in modo tale da permettere di apportare i 
cambiamenti appropriati, con tempi e costi ben inferiori da una parte e qualità di gran 
lunga superiore dall‟altra, rispetto all‟approccio manuale. 
Questa tesi si prefigge lo scopo di dare, a partire da un esempio applicativo, un riscontro 
all‟impiego del Reverse Engineering su un‟applicazione in esercizio. Vengono in 
particolare sviluppati i seguenti aspetti: 
 Metodologia e strumenti di documentazione di stampe di un‟applicazione. 
 Metodologia e strumenti di Reverse Engineering per la verifica di Business Rules 
(Design Recovery), che producono informazioni incoerenti (squadratura tra 
tabulati).
1 - Introduzione 
 
 
 
Il lavoro di tesi riguarda l‟attività di Reverse Engineering su un‟applicazione Cobol 
Main Frame, la procedura transiti, in esercizio presso INFRACOM (la società che 
gestisce il sistema informatico di Autostrade Brescia-Padova). L‟argomento è stato 
sviluppato durante lo svolgimento di uno stage presso la società. 
L‟obiettivo principale della tesi è in particolare quello di applicare l‟attività di Reverse 
Engineering a un caso concreto (la procedura transiti), per proporne i seguenti usi: 
a) Documentazione delle interfacce esterne (tabulati, reports,...) come espressione delle 
“Business Rules” presenti nel software. 
b) Criteri operativi per la verifica dell‟integrità/incoerenza delle informazioni gestite 
dall‟applicazione (verifica di squadrature tra tabulati). 
Gli obiettivi secondari sono: 
 Spiegare la metodologia del Reverse Engineering, fornendo una documentazione sul 
quadro tassonomico delle attività di ricerca e sviluppo in tale ambito (in particolare 
sull‟attività di “Estrazione delle Business Rules” e di “Data Reverse 
Engineering”/“Data Model Reconstruction”). 
 Evidenziare l‟uso di strumenti con i quali si può esplicare un‟attività di Reverse 
Engineering, realizzando delle economie di scala. 
L‟organizzazione della tesi consta di quattro parti: 
a) Modello concettuale delle entità attive su un Main Frame e loro censimento. 
b) Documentazione del quadro tassonomico dell‟attività di Reverse Engineering. 
c) Breve rassegna sugli strumenti utili a esplicare attività di Reverse Engineering. 
d) Applicazione della proposta a un caso concreto rilevato presso INFRACOM. 
L‟ultima parte comprende: 
 Censimento del sistema informativo in esercizio usufruendo del lavoro che la 
società PTQS ha in carico come attività di “Outsourcing Applicativo”. 
 Selezione di un‟area del sistema dove applicare l‟attività di Reverse Engineering. 
A questo lavoro, ci si auspica infine che seguano ulteriori attività di ricerca e di 
impiego, da parte delle aziende, del Reverse Engineering per i seguenti motivi: 
 Vasto campo di applicazione nell‟ambito della ristrutturazione, o meglio ancora 
della ricostruzione, delle applicazioni informatiche. 
 Per le economie di scala, tempi e costi, che attraverso questa metodologia si 
riescono a realizzare. 
Si ringrazia la società e il personale per l‟opportunità offerta.
2 - Il sistema di produzione 
 
 
 
 
 
 
 
 
 
 
 
In questo capitolo viene presentato un modello astratto di un sistema di produzione 
tipico per la gestione di grandi quantità di dati, implementato su un sistema Main 
Frame. Vengono approfondite le parti principali che lo compongono, partendo dal 
sistema operativo (MVS/XA) dell’IBM, si prosegue con il linguaggio dei comandi 
(JCL). Vengono descritti a grandi linee i due ambienti operativi disponibili sulle 
architetture Main frame: si mettono a confronto le caratteristiche dell’ambiente batch 
con l’ambiente on-line per introdurre il gestore delle transazioni on-line (CICS). Si 
conclude con il Data Base Management System (DB-2) e gli archivi (file VSAM).
8 - TECNICHE DI REVERSE ENGINEERING IN RICONVERSIONI DI SISTEMI MAIN FRAME, ZARATTINI ALBERTO 
 
 
2.1 Modello astratto di un sistema Main Frame 
Il sistema informatico presso INFRACOM è di tipo Main Frame, data l‟elevata 
complessità del sistema in esercizio non è possibile farne una descrizione dettagliata. 
Vengono perciò evidenziati i legami tra le macroentità che lo costituiscono facendo 
riferimento a un modello astratto di un sistema Main Frame (figura 2.1). 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 2.1. Modello astratto di un sistema Main Frame in esercizio 
Archivi 
(File VSAM) 
Programma 
SISTEMA OPERATIVO 
 
MVS/XA 
CICS 
DBMS 
Data Base 
JCL 
      Transazione
CAPITOLO 2: IL SISTEMA DI PRODUZIONE - 9 
 
A questo punto risulta utile fornire una spiegazione sintetica delle entità coinvolte per 
avere una visione d‟insieme, che verrà successivamente approfondita. 
Nello schema si possono identificare cinque entità fondamentali: 
 MVS/XA: è il sistema operativo IBM. 
 JCL: è il linguaggio dei comandi che collega i programmi al sistema operativo e 
attraverso cui si informa il sistema operativo stesso delle risorse necessarie al 
programma per svolgere i suoi compiti. 
 CICS: è il gestore della transazioni on-line, che fornisce al programma le risorse e 
le funzionalità necessarie per effettuare una transazione on-line. 
 DBMS: (Data Base Management System) fornisce le funzionalità necessarie per 
gestire, sia in termini descrittivi (Data Description Language DDL) che di accesso 
(Data Manipulation Language DML), attraverso particolari strutture (gerarchiche, 
reticolari, relazionali,...) e metodi, i dati. Nel sistema informatico in INFRACOM è 
rappresentato dal DB-2. 
 Archivi: sono generalmente file VSAM. 
A queste entità se ne aggiungono altre, sviluppate dagli addetti all‟informatica che 
costituiscono il software applicativo. Queste entità sono: 
 Base di dati: utilizzati per rappresentare le informazioni di interesse per un sistema 
informativo. 
 Programma: è una qualsiasi applicazione che viene eseguita nel sistema. 
 Transazione: richiesta applicativa dell‟utente del sistema. 
 
2.2 MVS/XA (Multiple Virtual Storage/eXtended Architecture) 
Un sistema operativo è un insieme di programmi di sistema che consentono ai 
programmi utente di essere eseguiti, ne controllano l‟esecuzione e forniscono quanto 
serve per l‟utilizzazione delle componenti hardware. L‟introduzione dei sistemi a 
memoria virtuale è nata dall‟esigenza di supportare un elevato numero di applicazioni 
contemporanee in ambienti di tipo diverso, con possibilità di multielaborazione. 
L‟MVS/XA è, come detto in precedenza, un‟estensione dell‟ MVS/370; le differenze 
più significative sono: 
 Indirizzamento a 31 bit: comporta un‟estensione della memoria a 2 GB, che 
rappresenta un notevole aumento rispetto alla memoria di 16 MB 
dell‟indirizzamento a 24 bit del sistema operativo MVS/370. 
 Channel Subsystem: consente di gestire le operazioni di I/O indipendentemente dalla 
CPU.
10 - TECNICHE DI REVERSE ENGINEERING IN RICONVERSIONI DI SISTEMI MAIN FRAME, ZARATTINI ALBERTO 
 
 
Principali componenti dell’MVS/XA 
I principali componenti dell‟MVS/XA sono: 
 Memoria Virtuale: è un‟entità astratta che nasce dalla combinazione della memoria 
reale e della memoria esterna (memoria di massa). L‟ampiezza della memoria 
virtuale è limitata dallo schema di indirizzamento del computer. 
 Address Space: è lo spazio di memoria virtuale assegnata a un job o ad un utente. 
 Task Management: il sistema operativo MVS/XA suddivide ogni job in unità di 
lavoro separate dette task. I vari task concorrono per usare le risorse del sistema, il 
controllo è affidato al supervisore, un componente del sistema operativo, che alloca 
le risorse e mantiene le informazioni riguardanti ogni task in modo che 
l‟elaborazione possa riprendere dal punto esatto in caso di errore. 
 Control Block: sono aree in cui vengono memorizzate le informazioni necessarie per 
gestire le risorse; ne esistono tre tipi: di sistema, di risorse, di task. 
 Input/Output e Data Management: la maggior parte dei task coinvolgono dati di I/O 
e il sistema operativo li gestisce tramite i data set che possono essere: sequenziali, 
ad accesso diretto, partitioned, sequenziali ad indice. 
 
Generazione e avviamento del sistema 
Il sistema per lavorare ha bisogno di essere inizializzato. La fase di generazione del 
sistema o SYSGEN consiste nello stabilire dei valori che consentono di adattarlo alle 
varie esigenze del centro in cui viene installato. 
L‟avviamento del sistema o IPL (Initial Program Loading), è una semplice procedura 
con la quale il sistema operativo viene portato in memoria. In realtà, ciò che viene 
portato in memoria non è l‟intero sistema ma solo il nucleo, cioè l‟insieme di 
programmi contenuti in SYS1.NUCLEUS, indispensabili per il funzionamento del 
sistema stesso. Gli altri programmi facenti parte del sistema operativo normalmente 
risiedono su SYSRES e vengono portati in memoria solo quando richiesto. Tale 
procedura viene normalmente avviata dall‟operatore all‟inizio di ogni sessione di 
lavoro. 
 
Librerie dell’MVS/XA 
La maggior parte dei programmi dell‟MVS sono contenuti in speciali librerie di data set 
partitioned. I programmi sono membri di questi data set partitioned. Di seguito 
elenchiamo alcune delle principali librerie: 
 SYS.NUCLEUS per i programmi del supervisore residente. 
 SYS1.LINKLIB per i programmi di sistema e utente non residenti. 
 SYS1.PROCLIB per le procedure. 
 SYS1.PARMLIB per i parametri di sistema. 
 SYS1.COBLIB per i moduli del compilatore Cobol. 
 SYS1.FORTLIB per i moduli del compilatore Fortran.
CAPITOLO 2: IL SISTEMA DI PRODUZIONE - 11 
 
JES (Job Entry Subsystem) 
E‟ un sottosistema con diverse componenti che provvedono alla gestione dei job prima e 
dopo l‟esecuzione (l‟MVS/XA li gestisce durante l‟esecuzione). 
Il JES assicura che le richieste di un job siano fatte in modo appropriato, le traduce in 
forma opportuna e pone il job nell‟esatta categoria per l‟elaborazione. Il JES legge un 
job da un input stream (insieme di schede JCL e dati input) e pone ogni job su uno spool 
device (device ad accesso diretto). Poichè nelle schede JCL relative ad un job è 
specificata la classe di input, la priorità, la classe di output, il JES seleziona i job per 
l‟elaborazione da uno spool device in modo da assicurare l‟allocazione delle risorse. 
Ogni job viene gestito dal JES in 6 fasi: 
 Input. 
 Conversione/interpretazione. 
 Allocazione device. 
 Schedulazione per l‟esecuzione. 
 Output. 
 Purge. 
Durante le varie fasi vengono impiegati i vari programmi che costituiscono il JES quali, 
ad esempio, l‟Internal Reader (fase di input), l‟External Writer (fase di output). Esistono 
due versioni del JES: JES2 e JES3. Pur essendo entrambi compatibili uno solo di essi 
viene scelto come sottosistema e tale scelta viene fatta in fase di generazione del 
sistema.
12 - TECNICHE DI REVERSE ENGINEERING IN RICONVERSIONI DI SISTEMI MAIN FRAME, ZARATTINI ALBERTO 
 
 
2.3 JCL (Job Control Language) 
Il Job Control Language è il linguaggio che permette di collegare i programmi al 
sistema operativo in cui essi devono operare. In sostanza il JCL informa il sistema 
operativo circa: 
a) Chi è che intende iniziare un lavoro (job). 
b) Quali sono le modalità generali che vuole adottare. 
c) Cosa intende eseguire ossia quali programmi desidera usare. 
d) Quali sono le risorse che ogni programma dovrà usare. 
Ogni lavoro (job) sottomesso al sistema operativo sarà dunque caratterizzato da una 
struttura predefinita in grado di fornire tutte le informazioni necessarie alla sua corretta 
esecuzione. Vediamo ora in dettaglio le caratteristiche principali. 
 
Schede del JCL 
Lo scopo del JCL è definire il nome di ciascun job, i programmi che devono essere 
eseguiti in ogni step e la sequenza degli step. Per assolvere le sue funzioni utilizzano le 
seguenti schede: 
 JOB: segna l‟inizio di un job e assegna il nome ad un job. 
 EXEC: identifica il programma da eseguire in ogni job step. 
 DD: descrive i data set da usare in ogni job step. 
 COMANDI OPERATORE: inseriscono comandi da console nella job stream. 
 NULL: segnalano la fine del job. 
 DELIMITER: segnala la fine del data set nell‟input stream. 
 PROC: segna l‟inizio della procedure JCL. 
 PEND: segnala la fine di una procedura in-stream. 
 COMMENTI: forniscono documentazione e commenti per il job. 
Le schede più importanti sono le prime tre: JOB, EXEC DD. Una precisazione per 
quanto riguarda la scheda COMANDI, che è usata per comunicare i comandi al sistema 
attraverso la Input Job Stream, generalmente è utilizzata solo dagli operatori 
direttamente da console, questo perché i comandi inseriti nel JCL vengono eseguiti dal 
JES2 appena letti, senza assicurare alcuna sincronizzazione con l‟esecuzione del job. 
 
Struttura e regole delle schede JCL 
Le schede JCL sono riconosciute dal sistema dalle barre in colonna 1 e 2 e hanno 
normalmente quattro campi distinti. Essi sono nell‟ordine: 
//NOME OPERAZIONE OPERANDI  COMMENTI 
Ogni campo è caratterizzato da delle regole precise che andiamo ad illustrare. 
Il campo NOME deve: 
 Identificare la scheda JCL affinchè altre schede JCL e i messaggi MVS possano 
farvi riferimento.
CAPITOLO 2: IL SISTEMA DI PRODUZIONE - 13 
 
 Iniziare a colonna 3 subito dopo le due barre. 
 Essere composto da uno a otto caratteri alfanumerici o national ($,£,§). 
 Iniziare con un carattere alfabetico o national ma non numerico. 
Il campo OPERAZIONE deve: 
 Specificare il tipo o la funzione della scheda JCL. 
 Seguire il campo NOME. 
 Essere separato dal campo NOME da una o più colonne bianche. 
 Non deve contenere caratteri speciali. 
Il campo OPERANDO: 
 Specifica le opzioni scelte per quella particolare scheda. 
 Deve seguire il campo OPERAZIONE. 
 Deve essere separato dal campo OPERAZIONE da una o più colonne bianche. 
 Può avere parametri, o opzioni multiple, separati tra loro da virgole. 
 Non può avere colonne bianche tra parametri. 
 Può estendersi nella scheda JCL seguente chiamata in questo caso scheda “di 
continuazione”. 
L‟ultimo campo, COMMENTI, è facoltativo e: 
 Fornisce informazioni o documentazione utile all‟utente. 
 Deve seguire il campo OPERANDO. 
 Deve essere separato dal campo OPERANDO da una o più colonne bianche. 
 Se il campo OPERANDO dovesse continuare nella scheda successiva, i commenti 
possono essere inseriti nella prima scheda, ammesso che vi sia posto. 
Vedremo di seguito le tre schede più importanti soffermandoci maggiormente 
sull‟ultima, la scheda DD. 
 
Le schede JOB e EXEC 
Ogni job MVS deve avere un nome che lo identifica all‟operatore; ci può essere solo 
una scheda JOB in un job MVS, e deve essere la prima scheda JCL nel job. Il suo 
formato è il seguente: 
//JOBNAME  JOB  OPERANDI  COMMENTI 
Il formato della scheda EXEC è il seguente: 
//STEPNAME  EXEC  OPERANDI  COMMENTI 
Lo STEPNAME non è un parametro obbligatorio, ma l‟uso di STEPNAME individuali 
ed univoci permetterà una più facile identificazione e un più facile riferimento ad ogni 
job step. 
Nella scheda EXEC c‟è solo un operando posizionale, che può esere uno dei seguenti 
tre parametri: 
 PGM = nome del programma da eseguire in questo step. 
 PROC = nome della procedura JCL da richiamare per questo step.
14 - TECNICHE DI REVERSE ENGINEERING IN RICONVERSIONI DI SISTEMI MAIN FRAME, ZARATTINI ALBERTO 
 
 
 NOME = nome della procedura JCL da richiamare per questo step. 
 
La scheda DD 
Il formato della scheda DD è: 
//DDNAME  DD  OPERANDI  COMMENTI 
Ogni scheda DD è identificata, e distinta, dal suo DDNAME che deve rispettare le 
seguenti regole: 
 Deve iniziare a colonna 3. 
 E‟ composto da uno a otto caratteri alfanumerici o national. 
 Deve iniziare con un carattere alfabetico o national. 
 Non può contenere caratteri speciali. 
 Deve essere unico nell‟ambito del job step. 
 Deve corrispondere al DDNAME nel data control block (DCB) che descrive il 
dataset nel programma sorgente. 
 
DSNAME: è un parametro che si usa per specificare il nome di un data set, rappresenta 
cioè il nome fisico dell‟archivio da usare. Per un data set che deve essere creato (NEW), 
il DSNAME fornisce il nome che verrà assegnato al data set dopo la creazione, mentre 
per un data set esistente (OLD) il DSNAME serve per trovare il data set. 
 
2.4 Ambienti operativi 
Vengono descritte le caratteristiche principali degli ambienti operativi del sistema di 
produzione: l‟ambiente batch e l‟ambiente on-line. Viene spiegato perché nasce 
l‟esigenza di un gestore dell‟ambiente on-line. 
La caratteristica principale che contraddistingue un‟applicazione batch, detta anche job, 
è l‟assenza di interazione tra l‟utente e quest‟ultimo. Il job viene preparato e sottoposto 
al sistema e dopo un certo lasso di tempo (minuti, ore o giorni) si ottiene l‟output. 
Generalmente, un‟applicazione batch, è idonea all‟esecuzione di job di grandi 
dimensioni, che consultano archivi e registrano i dati elaborati su file.  
La struttura del programma che, associato a un certo task, si occuperà di tale 
elaborazione può essere così schematizzata: 
 Inizializzazione delle aree e variabili del programma. 
 Apertura degli archivi. 
 Routine di input per la lettura dei dati da elaborare. 
 Elaborazione dei dati. 
 Scrittura dei dati elaborati. 
 Gestione di condizione anomale. 
In particolare tutti i file devono essere descritti usando proposizioni dipendenti dal 
linguaggio e dal sistema operativo utilizzati e devono essere aperti all‟inizio 
dell‟elaborazione e chiusi al termine della gestione dei file stessi.