GENERALI

La conversione dei programmi personali in ILE è obbligatoria per il funzionamento grafico.
E' comunque caldamente consigliata anche se non si vuol attivare subito questa possibilità, in modo da poter testare in modo completo l'applicazione in ILE.
Questo documento contiene una guida al processo di conversione, compresi gli aggiustamenti che bisogna realizzare a mano, ed una serie di diversità di comportamento tra l'RPG e l'ILE che abbiamo riscontrato e che potrebbero essere causa di comportamenti anomali.

Prima di iniziare la conversione è quindi opportuno leggereTUTTOquesto documento.

CONVERSIONE

La conversione dei file sorgenti personali può essere eseguita seguendo questa traccia:

1. Ridenominare i file sorgenti XXX (lungo 92 caratteri) in XXX_92
   
2. Creare l file sorgenti XXX lungo 112 caratteri
   
3. Copiare tutti i membri del file XXX_92 al file XXX
   
4. Convertire i sorgenti RPG che si intende passare in ILE dal file XXX_92 al file XXX., mediante:
   
   1. il tool di massa richiamabile con il comando CALL B£UT11, tipo elaborazione 2 (conversione RPGLE)
      
   2. opzione IS del pdm a livello di singolo membro
      
5. Se l'applicazione sarà completamente in ILE, modificare il tipo di questi sorgenti da CLP a CLLE.
   
6. Compilare tutti i sorgenti del file XXX, mediante:
   
   1. Il tool di massa richiamabile con il comando CALL B£UT11, tipo elaborazione 1 (compilazione)
      
   2. opzione CO del pdm a livello di singolo membro
      
7. Qualora ci fossero sorgenti che non si compilano, esaminare se il motivo è compreso tra quelli esposti nel paragrafo 'Particolarità del linguaggio' ed eseguire le correzioni opportune.
   
8. Dopo le verifiche di corretto funzionamento, eliminare il file XXX_92.
   

Con questa operazione si ha l'effetto collaterale inevitabile di perdere, in XXX, la data di ultimo aggiornamento del membro sorgente.

Riferirsi alla documentazione attiva di SERV_UP (Client grafico / Istruzioni per compilare) per una esposizione dettagliata del comando CO.

E' stata fissata la convenzione che i sorgenti di esempio si chiamino xxx_ES, dove xxx può essere RPGLE, CLLE, DSPF, ecc.
In questo rilascio TUTTI gli esempi sono stati trasformati in xxx_ES, in modo da ridurre la libreria degli oggetti.
Se quindi qualcuno usava direttamente gli oggetti della libreria standard, si deve preoccupare di muoverli in quella di personalizzazione.
Lo sviluppo si ritiene infatti libero di modificare gli esempi (al loro interno, non il colloquio) senza comunicare alcunché agli installatori, a meno che si introducano novità che meritano una NEWS.

PARTICOLARITA' DEL LINGUAGGIO

Non si può usare il nome NOT per variabili e routines: è diventato un nome riservato (serve per la negazione nelle espressioni logiche).

In caso di presenza nel sorgente di /COPY di prima pagina di QPRIGEN (convertito dal tool in QPRIILE), occorre convertire la COPY (con il comando IS), da QPRIGEN a QPRIILE, ponendo attenzione al tipo membro che deve essere RPG per essere convertito.
Qualora si volessero in futuro creare nuove /COPY di questo tipo, si dovrà seguire sempre lo stesso procedimento (crearle in RPG e convertirle in ILE).

Stessa cosa per QTRAGEN (usata solo in un programma esempio di ED).

Le specifiche I, in RPG, si dividono in specifiche di file e di DS. Le prime devono precedere le seconde. In ILE invece le specifiche DS diventano D e precedono le I di file. Il convertitore, se riconosce i due tipi di specifiche, esegue il riordinamento corretto.
Purtroppo, spesso tale distinzione dipende dalle /COPY, che non sono interpretate dal convertitore, con l'effetto di considerare tutte le specifiche I di file ed ottenere una conversione errata..
Per far distinguere al convertitore le specifiche I e le DS (in caso di specifiche I di file: ridenominazione di campi o introduzione di livelli di rottura L1, L2) si può fare così: inserire nell' RPG originale, prima della /COPY £PDS, una riga con DS in posizione 18 - 19, convertire in ILE, e poi toglierla dal sorgente convertito in RPGLE.

CONVERSIONE SCHIERE NEI VISUALIZZATORI DI P5

E' stata riscontrata una anomalia nel convertitore da RPG a ILE: in certe situazioni vengono spostate le schiere definite a tempo di compilazione, se definite, a livello di specifica D (ex E) in /COPY.
Questo errore è stato riscontrato con la /COPY £G35E, che è usata nei programmi personali di dichiarazione attività (normalmente P5AT10_xx).
In fondo al programma vi sono due schiere correlate: la prima da 1 a 8, la seconda da 10 a 13. In conversione quest'ultima viene spostata a destra di due posizioni. Va riportata a mano nelle posizioni originali.

PROGRAMMI DI ALTRE APPLICAZIONI

Per quanto riguarda le librerie SRC_xx di altre applicazioni, i sorgenti RPG sono stati convertiti in ILE. Non abbiamo però la possibilità di compilarli, quindi questa attività è demandata alle installazioni: sono gradite tempestive segnalazioni di anomalie.

CS

Le /COPY £CS0CA1E e £CS0CA1DS sono state modificate nel seguente modo: le schiere sono state definite nella DS e la E è stata svuotata. Si mantiene per compatibilità col passato (non si toccano i pgm convertiti) ma in quelli nuovi in ILE la E non serve più.
Inoltre, per gestire adesso la compresenza, la £CS0CA1DS è stata messa in QRPGGEN come I£CS0CA1DS (eccezione rispetto a I:_xx perché troppo lunga, trattata in B£UT11R1).
Nota per lo sviluppo standard: se in QRPGGEN si vuole definire una /COPY ILE con lo stesso nome di quella RPG ma con comportamento diverso, la s deve chiamare I_xxx: verrà copiata in QILEGEN come xxx. Se essa è più lunga di 8 caratteri la si gestisce come eccezione nel programma di conversione B£UT11R1.

D5

La £D5CE è stata modificata includendo la DS di D5COSO e la sottodefinizione dei suoi campi come schiera D50. Nei programmi che la usano, bisogna eliminare questa DS e la sottostante definizione della schiera D50.

D9

Stessa operazione di inglobamento nella DS e svuotamento della E è stata effettuata sulla £D9B.
Sulle /COPY £D9xxx è stato fatto anche un intervento più sostanziale, utilizzando la tecnica di inserire una /COPY in un sorgente /COPY, disponibile solo i ILE. Questo intervento ha reso però necessario la conversione definitiva di tutte le /COPY £D9xxx in ILE, eliminando definitivamente la versione in RPGIII.
In questa situazione bisognerà però intervenire sugli estrattori utente, convertendoli tutti OBBLIGATORIAMENTE in ILE ed apportando le modifiche sotto descritte.

Gli estrattori hanno due programmi:

• D9AP_xxC : contengono sia la /COPY £D9BE sia la £D9BDS. I pgm esistenti vanno bene (la E è superflua) e sui nuovi non si metterà più (lo imposteremo nell' RPGLE di esempio)
  
• D9AP_xxP: contengono solo la /COPY £D9BE: in essi si deve trasformarla negli estrattori standard e specifici in £D9BDS. (imposteremo anche questo nell' RPGLE di esempio).
  

La /COPY £D9AP_C1 contiene sia specifiche I (DS) sia specifiche C. In ILE è stata separata in due /COPY: £D9AP_D1 e £D9AP_C1, in quanto non sono necessariamente contigue: in mezzo ci potrebbero essere delle specifiche I vere. Quindi nei programmi che usano la £D9AP_C1, occorre aggiungere, tra le /COPY D la £D9AP_D1, prima delle eventuali specifiche I interne (vedi ad esempio D9AP_08C). Se non ce ne sono, si può mettere immediatamente prima della £D9AP_C1.

M5

La /COPY £M5M5H_C01, usata solo nell'ATP è stata modificata in ILE direttamente in QRPGGEN di SMEDEV, (tutti i pgm che la usano sono stati trasformati in ILE). Non si è fatta l'eccezione in B£UT11R1 (è lunga 10 caratteri) perché è usata solo da pgm standard di M5.

P5

La /COPY £P5DCDWI contiene specifiche I vere, quindi va spostata alla fine delle definizioni, subito prima delle C.

NOTA GENERALE RETURN / RT

Questa nota non c'entra con l'ILE ma ci siamo accorti di un potenziale problema generale.
Se un programma finisce con una RETURN con l'indicatore LR acceso, non viene eseguita la parte della £INZSR che esegue il reclaim resources (chiusura file e programmi dipendenti).
Per ovviare a questo errore, bisogna, dopo aver acceso l' LR, andare a fine programma, e sostituire il RETURN con la SETON RT. (NB: possono essere accesi sia l' LR sia l'RT, nel qual caso LR vince).

Queste situazioni sono aumentate da quando, in previsione della conversione all'ILE, abbiamo sostituito la FREE con una CALL con funzione 'LR'

Esempio:

---

va modificata così:

---

Se invece un programma va a fine main, con LR acceso (in modo condizionato) e l'ultima istruzione è una RETURN, essa va sostituita con una SETON RT.

NOTA SUI CLP/CLLE

I CLP diventano CLLE in modo da poter essere debuggati insieme agli RPGLE, ed inoltre per non introdurre nuovi gruppi di attivazione. Basta cambiarne il tipo.
Ci sono però alcune differenze di comportamento nella monitorizzazione dei messaggi.
Mentre in CLP i MONMSG del CPF0000 e CPF9999 sono equivalenti, in CLLE ci deve essere obbligatoriamente CPF0000.
Inoltre, se il programma CLLE 'A' esegue come prima istruzione MONMSG CPF0000 (gestione errori di default), quindi chiama il programma CLLE 'B', il quale non ha la gestione errori di default, e si produce un errore CPF, il programma B eredita dall'A la gestione errori, quindi non segnala il CPF.
Se invece si esegue una CALL ad un RPGLE monitorizzata con CPF0000 (localmente o all'inizio del CLLE), gli errori dell'RPGLE di tipo 'notifica' (con gravità bassa) sono monitorizzati in modo nascosto, ma possono provocare la fine prematura dell'esecuzione del programma.

PROBLEMA INDICATORI

In RPG un indicatore né '0' né '1', nei condizionamenti a sinistra viene assunto OFF, in ILE viene assunto ON.
Un esempio è il campo $IN35 in B£MDV5, dove può essere riempito con 'D'. Nel chiamante (ad esempio in B£G37G1) si muove poi $IN35 in *IN35. In ILE se non c'è '0' il 35 viene considerato acceso. In RPG invece è spento.

DEFINIZIONE SCHIERE

La seguente codifica (di specifiche 'D') :

---

produce l'effetto che XX2 è un campo di 1 carattere e non una schiera di 20 elementi di un
carattere (il LIKE fa ereditare solo il tipo di dato, lunghezza e decimali).

Per avere una equivalenza completa e parametrica, si deve scrivere invece:

---

Anche con il *LIKE DEFINE quello che si definisce è sempre un campo e non una schiera.

CONTROLLO NUMERO PARAMETRI IN LANCIO

L' RPG, nel caso di numero diverso di parametri tra chiamante e chiamato assumeva il seguente comportamento:

• Parametri del chiamante > dei parametri del chiamato: comportamento ammesso.
  

Nel chiamato, per usare un parametro, si testa che sia stato passato (con il numero parametri £PDSNP).

• Parametri del chiamante < dei parametri del chiamato: segnalazione di errore (CPF).
  

Nell'ILE questo secondo comportamento è ammesso. Ci sono dei sottoprodotti positivi: se si aggiunge un parametro al lancio di un programma di aggiustamento, non è necessario modificare la entry di tutti i programmi di aggiustamento dello stesso tipo, ma solo di quelli che usano il nuovo parametro. Per contro, gli eventuali errori di chiamata vengono mascherati.

EFFETTI COLLATERALI DELLA READC

L'istruzione READC di lettura record modificati di un subfile in programmi ILE reimposta il valore della variabile £KEY con il codice del tasto funzionale premuto sull'ultimo formato video emesso. In un programma RPG questo non avveniva.
Normalmente il test sulla £KEY avviene subito dopo l'emissione del formato e quindi non dovrebbero esserci molti punti in cui si possono verificare comportamenti anomali. Basta salvare la £KEY dopo l'emissione e controllare questo campo.