Tutti i programmatori RPG conoscono e usano con profitto le Strutture Dati.
Queste infatti danno la possibilità di impostare i dati in modo organizzato, e di accedere alle informazioni con semplicità, riferendosi o al singolo campo, o all'intera struttura.
Vediamo un esempio piuttosto semplice
DDataGMA DS
D Giorno 2S 0
D Mese 2S 0
D Anno 4S 0
Qui possiamo fare riferimento ala DS "DataGMA" per passarla come parametro a un altro programma (che ovviamente dovrà riceverla e avere una DS uguale), oppure riferirci ai suoi campi interni, o sottocampi.
Una cosa da tenere presente è che nell'RPG ILE, i campi devono essere univoci, per cui in un'altra DS non potremo avere un altro campo che si chiama "ANNO".
A meno che non usiamo un trucchetto simpatico e, a mio avviso, molto utile, che ci permetterà per prima cosa di rendere più comprensibili i nostri programmi, e per seconda di utilizzare un codice operativo nuovo (nell'RPG) che arriva direttamente dal cugino COBOL.
Ma andiamo con ordine: come facciamo a definire gli stessi campi in due DS diverse?
Semplicemente mettendo, a livello della definizione della DS, nell'area dedicata alle parole chiave, il comando QUALIFIED.
Questa istruzione ha l'unico difetto di obbligarci di riferirci ai vari campi indicando anche di quale DS fanno parte.
Quindi supponiamo di avere, oltre alla DS indicata prima, quest'altra:
DDataAMG DS Qualified
D Anno 4S 0
D Mese 2S 0
D Giorno 2S 0
Entrambe devono avere la dicitura "qualified", ovviamente.
Bene, e ora?
Ora possiamo scrivere questo:
//free
DataAMG = DataDaInvertire;
DataGMA.Anno = DataAMG.Anno;
DataGMA.Mese = DataAMG.Mese;
DataGMA.Giorno = DataAMG.Giorno;
DataInvertita = DataGMA;
//end-free
Mi sembra molto chiaro cosa stiamo facendo, no?
Se invece di una data trattiamo con dati anagrafici, per esempio, potremmo avere una DS come questa:
DCliente DS Qualified
D Cognome 50A
D Nome 30A
D DataDiNascita 8S 0
A questo punto, nel nostro programma potremo riferirci (dovremo, n realtà), riferirci ai vari campi come
Cliente.cognome
Cliente.nome
Cliente.DataDiNascita
Già questo è piuttosto interessante, ma c'è una cosetta che può tornarci molto utile: il fatto che i campi di una DS possono riferirsi a un'altra DS.
Detta così sempra una fesseria, ma provate a pensare alla DS del Cliente in questo nuovo modo:
DCliente DS Qualified
D Cognome 50A
D Nome 30A
D DataDiNascita LikeDs(DataAMG)
Uhm, mi sembra di vedere la perplessità sui vostri volti, e una domanda sul vostro crapino: "Bello, ma a cosa serve?".
Diciamo che, anche se non indispensabile, permette di riferirsi ai vari campi in questo modo:
Cliente.Cognome
Cliente.Nome
Cliente.DataDiNascita.Anno
Cliente.DataDiNascita.Mese
Cliente.DataDiNascita.Giorno
Ridondante? Forse, anzi probabilmente lo è. Ma sfido chiunque a NON capire a cosa si riferisca un campo che si chiama Cliente.DataDiNascita.Anno!
Sempre meglio di CLDNA, tanto per dire :-)
Naturalmente qui potrete sbizzarrirvi come preferite.
Giocateci un po' e vedrete quante belle cose si possono fare.
Domani vi racconto di quello che si può fare con due DS qualificate.
Nessun commento:
Posta un commento