> Tech > Traitement dynamique des sous-fichiers

Traitement dynamique des sous-fichiers

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

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

Microsoft 365 : 5 erreurs de sécurité

Microsoft 365 : 5 erreurs de sécurité

A l’heure où les données des solutions Microsoft 365 sont devenues indispensables au bon fonctionnement de l’entreprise, êtes-vous certain de pouvoir compter sur votre plan de sécurité des données et de sauvegarde des identités ? Découvrez le Top 5 des erreurs à ne pas commettre et les meilleures pratiques recommandées par les Experts DIB France.

Tech - Par iTPro.fr - Publié le 24 juin 2010

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT