> Tech > Extraire des informations sur la taille des sous-fichiers

Extraire des informations sur la taille des sous-fichiers

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

La première chose à  savoir sur la variable de renvoi de QDFRtvFD est qu'elle est organisée en plusieurs catégories dont voici la liste

• formats de fichiers de base
• formats de fichiers
• formats d'enregistrements
• formats de champs
• formats de mots-clés
• formats du lieu d'utilisation

En

analysant le programme de service
DspFInfo, nous verrons que ces
catégories constituent une suite de
structures liées contenant des détails
de fichier écran.

La documentation de l’API contient
des tableaux montrant les formats et
les structures qu’ils contiennent. Vous
les consulterez pour savoir comment
traverser les divers formats et structures
pour trouver l’information pertinente.
Examinons une section du programme
de service DspFInfo pour le disséquer.

Le programme de service commence
par des définitions de prototypes
de procédure. Vos applications
utilisent les procédures RtvSflSize et
RtvSflPage, dont les prototypes apparaissent
en A. Ces procédures ont les
paramètres suivants :

• display file name – un paramètre
obligatoire qui indique le fichier
écran pour lequel on veut extraire
l’information

• display file library – un paramètre
obligatoire qui indique la bibliothèque
contenant le fichier écran
(les valeurs spéciales *CurLib et
*LibL sont autorisées)

• record format name – un paramètre
obligatoire qui indique le nom du
format de l’enregistrement de
contrôle de sous-fichier pour lequel
il faut extraire l’information

• API error structure – un paramètre
obligatoire qui communique des informations
d’erreur

• display mode – un paramètre facultatif
qui indique le mode d’affichage
pour lequel il faut extraire l’information
(valeurs correctes : *DS3 (par
défaut) et *DS4).

RtvSflSize et RtvSflPage appellent la
procédure RtvSflAttr (Retrieve Subfile
Attribute) pour obtenir l’attribut désiré.
RtvSflAttr (en B) est interne au
programme de service DspFInfo : les
programmes d’application ne l’utilisent
pas. Le prototype pour l’API
QDFRtvFD apparaît ensuite, en C.

Les procédures RtvSflSize et
RtvSflPage apparaissent après les prototypes.
Chacune de ces procédures
détermine simplement le mode d’affichage
(*DS3 ou *DS4) pour lequel il
faut extraire l’information, appelle la
procédure RtvSflAttr pour extraire sa
valeur d’attribut respective, et renvoie
la valeur à  son appelant. Si une
erreur se produit (BytesAvail <>
NoAPIError), la procédure renvoie une
valeur de zéro.

La procédure RtvSflAttr est la cheville
ouvrière du programme de service. Après avoir défini l’interface de
procédure et la variable à  renvoyer à 
son appelant, la procédure définit plusieurs
structures utilisées par l’API
QDFRtvFD. Pour faciliter la corrélation des structures de la procédure avec
celle des documents IBM, RtvSflAttr
utilise les noms trouvés dans la documentation
d’IBM pour ses noms de
structures.

La structure de données QDFFBASE
(en D) mappe la section du fichier
de base. Cette structure apparaît
toujours d’abord dans la variable de
renvoi de QDFRtvFD et marque le
point de départ de la navigation au travers
de cette variable. Outre un petit
nombre de détails sur le fichier écran
de base, QDFFBASE contient des informations
que vous utiliserez pour une
navigation plus poussée dans la variable
de renvoi. Il contient, par
exemple, le décalage ou offset (souschamp
OffsetToQDFFINFO) par rapport
à  la section d’en-tête du fichier.

Ensuite, la structure de données
QDFFINFO (en E) mappe la section
d’en-tête du fichier. Comme RtvSflAttr
n’utilise aucun des nombreux détails
du fichier écran logés dans cette structure,
ils n’apparaissent pas dans la définition
de structure des données. Notez
toutefois que QDFFINFO contient le
premier sous-champ, QDFFINFOLen.
Sa valeur indique la longueur réelle de
la portion de la section d’en-tête de fichier
de la variable de renvoi de
QDFRtvFD. Cette valeur est nécessaire
pour calculer l’information d’offset utilisée
dans la navigation.

En F, la structure de données QDFARFTE
mappe la table des formats
d’enregistrement. RtvSflAttr n’a besoin
que du nom de format d’enregistrement
(sous-champ RcdFmtEntry),
pour la navigation, de l’offset par
rapport à  la section d’en-tête
d’enregistrement (sous-chaîme
OffsetToQDFFRINF).

La structure de données QDFFRINF
(en G) mappe la section d’entête
d’enregistrement. Parmi les nombreux
détails de fichier écran trouvés
dans cette structure, RtvSflAttr n’en
utilise que deux : les sous-champs
Flags et OffsetToQDFFSFCR. Le souschamp
Flags est un octet dont les bits
déterminent certaines caractéristiques
du sous-fichier. RtvSflAttr utilise ce
sous-champ pour déterminer si un format
d’enregistrement spécifié est
un enregistrement de contrôle de
sous-fichier. OffsetToQDFFSFCR est nécessaire pour naviguer vers la portion
d’enregistrement de contrôle de
sous-fichier de la variable de renvoi de
QDFRtvFD.

En H, la structure de données
QDFFSFCR mappe l’enregistrement
de contrôle de sous-fichier. Cette
structure contient de nombreux détails
d’enregistrement de contrôle de
sous-fichier, y compris la taille du sousfichier
et les valeurs de page du sous-fichier
dans la sous-structure QDFFSFHR.
A noter que cette sous-structure
est un tableau à  deux éléments : un
pour le mode d’affichage *DS3 et un
pour *DS4.

Avant que RtvSflAttr puisse extraire
des détails du fichier écran avec l’API
QDFRtvFD, il doit déterminer la taille
de l’information du fichier écran et allouer
la quantité de stockage appropriée.
Les cartes C de la procédure
RtvSflAttr commencent par un appel
adressé à  l’API QDFRtvFD (procédure
prototypée RtvDspFDesc) et placent
dans la structure de données
RtvSizeInfo les huit premiers octets de
l’information du fichier écran. Après
l’appel de l’API, le sous-champ RtvSize
reflète la quantité de stockage nécessaire
pour contenir tous les détails du
fichier écran. La procédure alloue la
quantité de stockage nécessaire à  la
structure de données QDFFBASE,
qui est fondée sur le pointeur
QDFFBASEPtr.

Après avoir alloué le stockage,
RtvSflAttr extrait les détails du fichier
écran avec un autre appel adressé à 
l’API QDFRtvFD et stocke ces détails
dans la structure de données QDFFBASE.
A l’aide des offsets et des longueurs
de structure, la procédure navigue
ensuite dans cette structure de
données et extrait les informations demandées.

Comme première étape de navigation,
la procédure calcule un pointeur
vers la section d’en-tête de fichier
(QDFFINFOPtr) en ajoutant l’offset
à  la section d’en-tête de fichier
(OffsetToQDFFINFO) au pointeur vers
le format de base (QDFFBASEPtr). RtvSflAttr calcule ensuite un pointeur
vers la première entrée de la table des
formats d’enregistrement (QDFARF
TEPtr) en ajoutant la longueur de la
section d’en-tête de fichier (QDF
FINFOLen) au pointeur vers la section
d’en-tête de fichier (QDFFINFOPtr).

Ensuite, RtvSflAttr fait une recherche
dans la liste des formats d’enregistrement
que QDFRtvFD renvoie
et s’intéresse au format d’enregistrement
spécifié par son appelant. Quand
la procédure trouve le format d’enregistrement
correct, c’est la sous-routine
ProcessRcdFmt qui prend la main.
Elle calcule d’abord un pointeur vers la
section d’en-tête d’enregistrement
(QDFFRINFPtr) en ajoutant l’offset à  la
section d’en-tête d’enregistrement
(OffsetToQDFFRINF) au pointeur vers
la section d’en-tête de fichier
(OffsetToQDFFINFO). Ensuite, la sousroutine
teste le bit 2 dans le
sous-champ Flags pour déterminer si
le format d’enregistrement sélectionné
est un enregistrement de contrôle de
sous-fichier. Si c’est le cas, la sous-routine
calcule un pointeur vers le format
d’enregistrement de sous-fichier
(QDFFSFCRPtr) en ajoutant l’offset à 
l’enregistrement de contrôle de sousfichier
(OffsetToQDFFSFCR) au
pointeur de la section d’en-tête
d’enregistrement (QDFFRINFPtr). La
sous-routine finit en extrayant la valeur
d’attribut demandée pour le mode
d’affichage spécifié (*DS3 ou *DS4).
Après avoir extrait l’information demandée,
RtvSflAttr libère le stockage
alloué précédemment. Enfin, la procédure
renvoie la valeur d’attribut
demandée à  son appelant.

Téléchargez cette ressource

Cybersécurité des collectivités : Enjeux, Perspectives & Solutions

Cybersécurité des collectivités : Enjeux, Perspectives & Solutions

Villes, intercommunalités, métropoles, départements et régions sont particulièrement exposés aux risques de cybersécurité. Ce livre blanc Stormshield présente les défis cyber que rencontrent les collectivités, les solutions et perspectives pour qu’elles puissent assurer leur mission d’utilité publique, en toute sécurité.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT