Convertire un RPG III in RPG IV è meno drammatico di quanto la parola "migrazione" faccia pensare. Esiste un comando che fa il grosso del lavoro, e il risultato compila. Quello che il comando non può fare è riorganizzare il programma: e se ci si ferma alla conversione automatica, si ottiene un RPG IV che è ancora RPG III con una sintassi diversa.
Il comando
CVTRPGSRC FROMFILE(MIALIB/QRPGSRC)
FROMMBR(PGMORD)
TOFILE(MIALIB/QRPGLESRC)
TOMBR(*FROMMBR)
EXPCPY(*YES)
EXPCPY(*YES) espande le /COPY dentro il sorgente convertito. Vale la pena rifletterci: da un lato si vede tutto il codice in un posto solo, dall'altro si perde la condivisione. Su un programma che usa /COPY di tracciati condivisi da decine di programmi, conviene *NO e convertire le copy separatamente.
Il comando produce anche un report di conversione. Non va archiviato senza leggerlo: contiene l'elenco delle cose che non ha potuto tradurre, ed è la lista di lavoro.
Cosa si inceppa quasi sempre
Le chiamate con CALL e PARM. La conversione le lascia come sono e continuano a funzionare, ma restano chiamate dinamiche senza controllo sui parametri: se il chiamato cambia il numero o il tipo dei parametri, l'errore si scopre in esecuzione. Passare a CALLP con un prototipo sposta il controllo al momento della compilazione, ed è probabilmente il singolo miglioramento con il rapporto beneficio/fatica migliore.
Le aree di dati e i campi numerici lunghi. RPG IV consente campi packed più lunghi di quelli ammessi in RPG III. Un campo esteso "perché ora si può" cambia la lunghezza del record: se altri programmi leggono lo stesso file con il tracciato vecchio, si rompono. La lunghezza dei campi va cambiata solo con l'elenco in mano di chi usa quel file, che si ottiene con DSPPGMREF e DSPDBR.
Le date. RPG III le teneva in campi numerici a sei o sette cifre. RPG IV ha un tipo date vero, con aritmetica e conversioni. È una delle cose che conviene di più adottare — ma non durante la conversione: prima si converte lasciando tutto com'è, poi, a programma funzionante, si affronta un campo per volta.
Gli indicatori. Sopravvivono alla conversione e continuano a funzionare. Sostituirli con %found, %eof e %error si può fare gradualmente, ed è il passo che rende il codice leggibile a chi arriva dopo.
DFTACTGRP(*NO): la scelta che apre tutto
Un programma convertito e compilato così:
CRTBNDRPG PGM(MIALIB/PGMORD) DFTACTGRP(*YES)
funziona esattamente come prima, e va benissimo come primo passo. Ma con DFTACTGRP(*YES) non si possono legare service program né usare le procedure ILE: si è in RPG IV con le possibilità dell'RPG III.
Il passaggio a:
CRTBNDRPG PGM(MIALIB/PGMORD)
DFTACTGRP(*NO)
ACTGRP(*CALLER)
DBGVIEW(*SOURCE)
è ciò che sblocca l'ambiente ILE. Ha però una conseguenza da conoscere: cambia il comportamento in caso di errore non gestito e il modo in cui i file restano aperti fra una chiamata e l'altra. Su programmi che venivano richiamati molte volte in un ciclo, si può notare una differenza di prestazioni — in meglio o in peggio a seconda di come sono scritti. È il motivo per cui si converte un programma per volta e si prova.
DBGVIEW(*SOURCE) non serve al programma ma a chi lo manutiene: permette di fare il debug guardando il sorgente invece del codice generato.
Un ordine che riduce i rischi
- Convertire tutto, senza modificare niente, e compilare con
DFTACTGRP(*YES). Il risultato deve comportarsi in modo identico a prima. - Mettere in produzione questa fase. È il momento più delicato: se qualcosa si rompe, si rompe qui, e la causa è la conversione e nient'altro.
- Solo dopo, programma per programma, passare a
DFTACTGRP(*NO). - Su un programma alla volta, e solo quando lo si sta già toccando per altri motivi: prototipi al posto di
CALL, funzioni predefinite al posto degli indicatori, free-form al posto delle colonne.
Il punto 2 è quello che si tende a saltare, unendo conversione e riscrittura in un solo passaggio. È una cattiva idea: quando qualcosa non torna, non si sa più se è colpa della conversione o della riscrittura.
Cosa non conviene convertire
Un programma che gira da quindici anni, che nessuno tocca e che nessuno toccherà, non ha motivo di essere convertito. RPG III continua a compilare e a funzionare. La conversione ha senso dove c'è manutenzione: se un programma è già costato ore quest'anno, quelle ore diventeranno meno in RPG IV. Se invece non lo apre nessuno, la conversione è solo un rischio senza contropartita.
Su quali versioni funziona
CVTRPGSRC — il comando di conversione fa parte del compilatore ILE RPG ed è
disponibile da quando esiste RPG IV, cioè da V3R1. Su qualsiasi macchina in 7.x c'è.
CRTBNDRPG con DFTACTGRP(*NO) — disponibile da V3R1 con ILE. Non è una novità
recente: è il modello di compilazione standard da moltissimo tempo.
Il passaggio successivo al free-form richiede invece release recenti: le dichiarazioni
in free-form e **FREE esistono da IBM i 7.2 (o 7.1 con TR7 e la PTF del compilatore
SI51094). Se il sistema è su una release precedente, la conversione a RPG IV si può
comunque fare: si resta nel formato a colonne, che è esattamente ciò che il comando produce.
I prototipi e CALLP al posto di CALL/PARM esistono da V3R2 e non richiedono
niente di recente.
L'ordine consigliato nell'articolo vale su tutte le release: quello che cambia, sulle macchine più vecchie, è solo il punto 4 — il free-form non sarà disponibile, ma prototipi e funzioni predefinite sì.
Commenti
Nessun commento ancora. Sii il primo a commentare!
Devi avere un account per commentare. Accedi · Registrati