par Gary Guthrie - Mis en ligne le 11/03/2003
Combien de fois avez-vous dû modifier
la logique d'un programme parce
que vous aviez modifié les caractéristiques
de taille des sous-fichiers d'un fichier
écran ? Une simple modification
de la taille des sous-fichiers (mot-clé
DDS SflSiz) ou du nombre d'enregistrements
d'une page de sous-fichiers
(mot-clé DDS SflPag), et voilà qu'il faut
aussi modifier le programme pour qu'il
traite correctement les sous-fichiers ...Vous devrez peut-être, par exemple,
devoir modifier les routines qui chargent
le sous-fichier, qui en font le paging,
ou qui en traitent les enregistrements.
Et si l'on pouvait modifier les caractéristiques
de taille d'un sous-fichier
sans toucher à la logique du programme
? On le peut avec les
procédures RtvSflSize (Retrieve Subfile
Size) et RtvSflPage (Retrieve Subfile
Page) du programme de service
DspFInfo ! Ces procédures vous permettent
de créer les applications pour
qu'elles extraient les caractéristiques
de taille d'un sous-fichier à l'exécution
puis qu'elles utilisent cette information,
plutôt que des références codées
en dur, pour contrôler les routines
associées au sous-fichier.
Traitement dynamique des sous-fichiers
La cheville ouvrière des procédures
RtvSflSize et RtvSflPage est l’API
QDFRtvFD (Retrieve Display File
Description). Cette API permet d’extraire
des informations de fichier écran
détaillées selon la spécification du DDS
utilisé pour créer le fichier. L’appel de
l’API est simple : il suffit d’appeler QDFRtvFD et de passer les paramètres
suivants :
• Receiver variable – un paramètre de
sortie de longueur variable qui
contiendra les informations extraites
du fichier écran
• Length of receiver variable – un paramètre d’entrée qui définit la longueur
de la variable réceptrice
• Format name – un paramètre d’entrée
qui définit le format de la variable
réceptrice ; la valeur doit être
DSPF0100
• Qualified file name – un paramètre
d’entrée qui définit le fichier écran
(avec sa bibliothèque) pour lequel
l’information doit être extraite
• Error code – un paramètre d’entrée/
sortie de longueur variable qui
contient la structure d’erreur de
l’API standard
Nous verrons plus loin qu’il n’est
pas si simple d’utiliser l’information
renvoyée par l’API.
Un coup d’oeil à la documentation
de QDFRtvFD (http://publib. boulder.
ibm.com/pubs/html/as400/v5r1/ic2
924/Info/apis/qdfrtvfd.htm) montre
que l’API couvre beaucoup de terrain.
Non seulement QDFRtvFD renvoie un
gros volume d’informations, mais en y
regardant de plus près, on voit que son
organisation est complexe. L’API renvoie
tous les détails DDS utilisés dans
la création du fichier dans une variable
unique et il n’est pas facile d’associer
l’information aux nombreuses structures
dont les longueurs et les positions
varient.
Il n’est pas question ici de décrire
QDFRtvFD dans son intégralité. Je me
concentre plutôt sur les étapes de base
permettant de travailler avec l’API et
montre comment extraire la taille des
sous-fichiers et des valeurs de page de
sous-fichiers, des détails du fichier
écran renvoyé par QDFRtvFD. Les
techniques que je démontre vous permettront
d’extraire n’importe quel détail
de fichier écran qui vous intéresse.
Téléchargez cette ressource
Préparer l’entreprise aux technologies interconnectées
Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.
