PORTING DI APPLICAZIONI COBOL DA AMBIENTE MS-DOS A WINDOWS
Introduzione
Effettuare il porting di applicazioni realizzate in ambiente a carattere
verso un ambiente grafico come Windows, di solito comporta la riscrittura
di una notevole parte del codice esistente.
Inoltre se il codice non e' realizzato in modo pulito (e il Cobol
non e' il linguaggio migliore per questo scopo), questo diventa ancora
piu' difficile perche' si e' costretti riscrivere quasi completamente
il codice.
In effetti nell'ambiente a carattere la normale interazione tra il
programma Cobol e i dispositivi video e tastiera
e' il seguente:
PROG. COBOL DISPOSITIVO
...
...righe di codice...
ACCEPT --> Tastiera
...righe di codice...
DISPLAY --> Video
...righe di codice...
...
Cioe' il programma richiede ai dispositivi esistenti i dati relativi.
In ottica Windows questa modalita' di funzionamento non e' utilizzabile,
in quanto il programma viene attivato ad ogni evento dell'interfaccia
grafica (chick del mouse, caratteri inputati, ...).
Percio' il programma non avra' un andamento procedurale, ma Event-Driven.
WINDOWS PROG. WINDOWS
... ...
... Funzione GestioneEventi:
Tasto --> ...gestione dell'evento...
... ...
Mouse --> ...gestione dell'evento...
E' il sistema operativo che attiva una specifica funzione del programma
ad ogni evento, e questa deve gestire l'evento e provvedere
ad eseguire eventuali altre azioni relative.
Alla fine della gestione dell'evento il programma ritorna il controllo
al sistema operativo, e quindi non esegue nessuna istruzione finche'
non viene attivato per un nuovo evento.
Come risolvere il problema
Il problema apparentemente e' non risolvibile.
In realta' esiste una unica soluzione, quella da noi adottata, che spesso
non viene considerata, in quanto inusuale in una normale programmazione.
La soluzione consiste nello scorporamento della gestione degli eventi in
un processo diverso da quello che esegue tutte le operazioni di calcolo
in modalita' procedurale.
La parte procedurale esistente sara' lasciata inalterata, mentre il
processo di gestione della finestra (con gli eventi collegati) sara'
separato.
Quindi esistera' un processo con una modalita' di funzionamento
del tutto simile alla attuale, un processo in pura modalita' Windows
ed un protocollo di comunicazione tra i due processi.
Programma
Procedurale WVIDEO
+-----------+ ****** +-----------+
| | * * | |
| | -------> * * -------> | |
| | eventi * * eventi | |
| | <------- * * <------- | |
| | * * | |
+-----------+ ****** +-----------+
Nel seguito del documento le azioni che riguarderanno il protocollo
di comunicazione tra i due processi saranno definite genericamente
eventi.
Restrizioni
Le seguenti sono restrizioni che devono essere tenute in primo piano:
- deve essere garantita la massima compatibilita' con la versione
RVIDEO attuale (versione 34)
- deve essere segnalato ogni possibile miglioramento che, implementato
anche sulla RVIDEO, possa essere significativo, per esempio:
- riduzione dei parametri passati mediante common
- possibilita' di utilizzo del mouse anche in RVIDEO
Espansioni
Le seguenti sono espansioni che devono essere gestite dalla WVIDEO
rispetto alla RVIDEO:
- il Mouse deve essere utilizzato il piu' possibile in modalita'
Windows, quindi deve essere usato per esempio per il posizionamento
in un campo
-
Vantaggi e svantaggi della soluzione
Questa soluzione presenta sia vantaggi che svantaggi, i primi sono
sicuramente in vantaggio sui secondi.
Vantaggi
- Minime (o nessuna) modifica ai sorgenti MS-DOS.
Quindi generazione della applicazione MS-DOS e WIN da
un unico sorgente
- Possibilita' di rendere le parti fisse e i menu graficamente
molto curati per rendere l'applicazione simile a quelle native
di questo ambiente (con immagini, font particolari, ...)
- Nessuna modifica alla modalita' di lavoro del cliente
- Puo' costituire la prima parte di una migrazione dei programmi
in ambiente Windows
Svantaggi
- La modalita' di lavoro rimane caratterizzata da una sola finestra
attiva e la modalita' di presentazione dei dati corrisponde al
formato 25 righe per 80 colonne.
Realizzazione
La realizzazione della WVIDEO consiste dei seguenti passi:
Step | Descrizione | Risorse | Tempo |
Protos1 | Costruzione di prototipi di test. Servono per la verifica delle prestazioni | BEL,QUI,DAL | 26Nov97 |
WVIDEO1 | Implementazione versione semplice WVIDEO. Vengono sostituite solamente le ACCEPT e le DISPLAY con delle funzioni di rilancio verso WVIDEO | QUI,DAL | 5Dic97 |
WVIDEO2 | Implementazione versione completa WVIDEO. La logica di gestione dei campi viene delegata alla WVIDEO | DAL | 24Dic97 |
MENU | Definizione del layout dei menu | Pragma | 31Gen98 |
FIXED | Definizione delle parti fisse della maschera | Pragma | 31Gen98 |
dove:
BEL - Alberto Bellina (Pragma)
QUI - Luca Quintarelli (Pragma)
DAL - Andrea Dal Zovo (Eureka)
PRAGMA - Risorse varie in Pragma
Componenti
I componenti che di devono realizzare sono i seguenti:
- processo WVIDEO.EXE
- libreria PEVENT.DLL per la gestione degli eventi
- layer di interfaccia WIO.CBL
WVIDEO
Questo e' il programma che gestisce la finestra dove sono presentate
le maschere.
Il programma e' realizzato in Cobol Micro-Focus versione 4.0.
In successive versioni questa parte potra' essere realizzata in VisualBasic
o in altri linguaggi che consentano una gestione migliore delle parti
video.
PEVENT - Pragma Event DLL
Questa DLL contiene tutte le interfaccie necessarie per la gestione degli
eventi di colloquio e sincronizzazione tra il processo WVIDEO e il
processo utente ed alcune funzioni di utility.
Il sorgente e' PEvent.cbl.
Le funzioni presenti in questa DLL sono le seguenti:
Questa DLL e' realizzata in Cobol Micro-Focus versione 4.0.
PWIF - Pragma Windows I/F
Questa parte di software e' sostanzialmente una interfaccia verso
la parte WVIDEO e gli eventi.
Deve essere attaccato ad ogni programma che deve utilizzare la
WVIDEO.
Questo modulo e' realizzato in Cobol Micro-Focus versione 4.0.
Protocollo di Comunicazione tra i Processi
Il protocollo di comunicazione e' costituito in realta' da uno o entrambi
i seguenti metodi:
- Messaggi di Windows
- Memoria condivisa tra i due processi
Considerando che il processo WVIDEO e' in pura modalita' Windows, potra'
beneficiare dell'utilizzo dei meccanismi di spedizione e ricezioni dei
messaggi tipica di Windows che consente di spedire messaggi a qualsiasi
applicazione utilizzando l'identificatore della finestra (Window handle).
Il programma utente non avra' una finestra attiva quindi non potra'
ricevere messaggi.
Ci troviamo percio' in una situazione in cui il processo utente puo'
spedire messaggi alla WVIDEO, ma non viceversa.
Siamo percio' costretti ad utilizzare insieme od in alternativa
un sistema costituito da una memoria condivisa tra i due processi.
Possiamo percio' ipotizzare che la comunicazione dal processo utente
alla WVIDEO sia effettuato mediante i messaggi di Windows, mentre
la comunicazione in verso opposto sfutti la memoria condivisa.
Funzioni di interfaccia
Funzione CreateMappedMem
Questa funzione crea una area di memoria condivisa tra processi.
La lunghezza di questa area e' attualmente definita dalla costante
SHMEMSIZE definita nel file PEvent.cbl.
Funzione DestroyMappedMem
Questa funzione esegue la rimozione della zona di memoria condivisa.
Funzione SendPEvent
La funzione SendPEvent spedisce un evento alla controparte.
Questa funzione viene utilizzata sia per mandare un evento dal processo
utente alla WVIDEO, che viceversa.
All'interno della funzione viene automaticamente utilizzato il metodo
reale (SendMessage o Shared Memory) utilizzato.
Il prototipo di chiamata della funzione e' il seguente:
SendEvent( Evento, Parametro1, Parametro2 )
dove:
Evento e' il tipo di evento
Parametro1
Parametro2
Funzione WaitPEvent
Messaggi di Windows
I messaggi di Windows possono essere spediti mediante le seguenti
due funzioni:
La funzione SendMessage spedisce il messaggio in modalita' sincrona,
cioe' ritorna quando il messaggio e' arrivato al processo destinatario,
mentre la funzione PostMessage mette il messaggio nella
coda dei messaggi del processo e ritorna immediatamente.
Memoria Condivisa
La memoria condivisa tra i processi viene creata utilizzando il
meccanismo di Interprocess Communication propri di Win95.
Mediante tali metodi e' facilmente creabile una memoria condivisibile
tra piu' processi, con gestione automatica da parte di Windows della
cancellazione della stessa quando nessun processo la utilizza.
Questa modalita' viene definita Mapped Memory.
La memoria condivisa sara' suddivisa in campi con ognuno un significato
relativo al un operazione.
Formato Memoria Condivisa
Il formato della memoria condivisa e' il seguente:
01 SharedMem.
*> Flag per il ritorno di eventi dalla gestione video
*> Possono valere EVT-WAIT, EVT-RECEIVE
02 FlagAccept Pic 9.
02 RetAcceptChar.
03 RetAccept Pic x Comp-x.
02 ParamDisplay.
03 Stringa Pic X(80).
03 Lung Pic s9(Word-Len) comp-5 value 80.
03 Colonna Pic s9(Word-Len) comp-5 value 0.
03 Riga Pic s9(Word-Len) comp-5 value 0.
02 FlagDisplay Pic 9.
02 Filler Pic x(929).
Eventi
Tutte le operazioni tra i due processi sono semplicemente definite
eventi indipendentemente da come poi questi eventi sono
implementati.
Dopo la definizione degli eventi necessari ognuno sara' implementato
nel metodo piu' adeguato allo scopo (con Message o Memoria Condivisa).
Si possono definire due livelli di eventi, uno a piu' basso livello che
gestisce le singole operativita', come scrivere un messaggio a video
oppure ricevere un carattere, ed uno a piu' alto livello che consente
di assemblare una serie di eventi in un unico passo.
Tipi di Eventi
Gli eventi basso livello che ci necessitano saranno i seguenti:
Evento | Parametri | Originator | Descrizione |
evtDisplay | row, col, message | Prog | Scrive message alla posizione row, col |
evtAccept | - | Prog | Attende un tasto |
evtShow | - | Prog | Mostra la finestra |
evtHide | - | Prog | Nasconde la finestra, lasciando attivo il programma |
evtQuit | - | Prog | Termina il processo |
| | | |
WKEY | key | | Ritorna il tasto premuto |
WTITLE | title | | Aggiorna il titolo della finestra con quello passato |
| | | |
Gli eventi alto livello che ci necessitano saranno i seguenti:
Evento | Parametri | Descrizione |
WMASK | mask | Scrive le parti fisse della maschera nella finestra |
WREFRESH | mask | Esegue un rinfresco del contenuto della finestra |
WGETFIELD | field | Ritorna il dato inserito nel field |
| | |
| | |
Evento di Quit - evtQuit
L'evento evtQuit causa la terminazione del programma WVIDEO.
L'evento evtQuit viene spedito dal programma utente alla WVIDEO, che alla
ricezione si termina.
L'evento evtQuit non utilizza gli altri parametri.
Evento di Hide - evtHide
L'evento evtHide causa l'invisibilita' della finestra del programma WVIDEO.
L'evento evtHide viene spedito dal programma utente alla WVIDEO, che alla
ricezione esegue una chiamata ShowWindow con parametro HIDE.
L'evento evtHide non utilizza gli altri parametri.
Evento di Show - evtShow
L'evento evtShow causa la visibilita' della finestra del programma WVIDEO.
L'evento evtShow viene spedito dal programma utente alla WVIDEO, che alla
ricezione esegue una chiamata ShowWindow con parametro SHOW.
L'evento evtShow non utilizza gli altri parametri.
Evento di Display - evtDisplay
L'evento evtDisplay consente di scrivere una stringa nella finestra
del programma WVIDEO.
L'evento evtDisplay viene spedito dal programma utente alla WVIDEO, che alla
ricezione esegue delle chiamate alle appropriate API di Windows per
realizzare l'intento.
L'evento evtDisplay utilizza il parametro ParString per il passaggio
della stringa da stampare.
Il parametro ParString e' in realta' gestito come una struttura con i
seguenti campi:
01 ParamDisplay.
02 Stringa Pic X(80).
02 Lung Pic s9(Word-Len) comp-5.
02 Colonna Pic s9(Word-Len) comp-5.
02 Riga Pic s9(Word-Len) comp-5.
Evento di Accept - evtAccept
L'evento evtAccept consente di leggere un carattere premuto nella finestra
del programma WVIDEO.
L'evento evtAccept viene spedito dal programma utente alla WVIDEO, che alla
ricezione esegue delle chiamate alle appropriate API di Windows per
leggere il tasto.
L'evento evtAccept non utilizza i parametri in chiamata, mentre al
ritorno dalla funzione il parametro ParString ritornera' il codice
del tasto premuto.
Algoritmi
Essendo la gestione del dispositivo di I/O (tastiera e video) separate
dal processo utente sono necessati alcuni meccanismi di sincronismo.
Start di WVIDEO
WVIDEO viene startato dalla prima linea di codice alla partenza dei menu,
e la finestra viene predisposta nascosta con un evento di EvtHide.
Ad ogni voce di menu che corrisponde alla presentazione di una maschera
questa viene disegnata e poi la finestra viene mostrata con un evento di
EvtShow
USRCODE . WIN . WVIDEO
. .
Menu: . .
Create SHMEM . .
Start WVIDEO . .
Wait WVIDEO up . o <---.--- WVIDEO up and hide
MenuLoop: . .
... . .
Stop di WVIDEO
WVIDEO viene chiusa dalla ultima linea di codice alla terminazione dei menu,
e la finestra viene nascosta con un evento di EvtHide e viene
poi inviato un evento di EvtQuit che termina il processo WVIDEO.
USRCODE . WIN . WVIDEO
. .
Menu: . .
... . .
Quit menu: . .
EvtHide ---.--------------.---> hide the form
EvtQuit ---.--------------.---> terminate the program
Selezione/Deselezione di una maschera dal menu
Selezionando o deselezionamendo una voce di menu che corrisponde
alla presentazione di una
maschera le operazioni che vengono eseguite sono le seguenti:
USRCODE . WIN . WVIDEO
. .
MenuLoop: . .
... . .
select FORM . .
EvtForm ---.--------------.---> prepare the form
EvtShow ---.--------------.---> show the form
... . .
unselect FORM . .
EvtHide ---.--------------.---> hide the form
EvtClear ---.--------------.---> clear the form
... . .
Lettura di un tasto
Siccome la richiesta di lettura di un tasto e' effettuata dal codice utente
e la lettura vera e propria e' inserita nella WVIDEO e' necessario definire
un protocollo di scambio e sincronizzazione dei dati.
USRCODE . WIN . WVIDEO
. .
EvtGetKey() ---.--------------.--->
EvtWaitLoop() . . Wait for a key...
. o <---.--- EvtKey( char )
manage key <---.--- .
. .
Regole di realizzazione
Per la realizzazione del progetto e' necessario l'utilizzo di alcune regole
per la produzione del codice e della documentazione relativa.
Codice
Il codice realizzato deve avere le seguenti caratteristiche:
- essere chiaro mediante l'utilizzo di entry parametrizzate
- tutte le variabili devono essere significative
- le parti significative devono essere documentate all'interno
del codice stesso
- eventuali parti comuni devono essere inserite in DLL
Documentazione
La documentazione deve consentire la manutenzione, la modifica e
l'espansione di tutto il codice creato.
Deve essere fornita un documentazione in formato testuale da cui
sara' ricavata una documentazione ipertestuale in formato .html.
Devono essere documentate le seguenti parti:
- funzionalita'
- funzioni (o entry) e parametri relativi
- step di compilazione, linking
- modalita' di attivazione
- limiti se esistenti
Last version: 21 Nov 1997