> Tech > Le programme BSEARCH

Le programme BSEARCH

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

Le programme ILE BSEARCH utilise la fonction C bsearch pour explorer un tableau utilisé au moment de la compilation, contenant les noms de villes suivants : Albuquerque, Boston, Chicago, Denver, Fairbanks, Honolulu, Indianapolis, Los Angeles, New York et Omaha.
Le programme admet un nom de ville (distinguant les majuscules des

minuscules)
comme seul paramètre. Il utilise ensuite la fonction C bsearch pour déterminer
si le paramètre transmis correspond à  l’une des entrées du tableau. Ainsi, si
l’on invoque ce programme avec la commande AS/400 suivante



Call BSEARCH Parm( ‘Chicago’ )



on obtient l’écran illustré par la figure 9. Il indique simplement que l’entrée
‘Chicago’ a été trouvée dans le tableau. Si on appelle le programme en transmettant
un nom de ville absent du tableau, il affiche le message  » Not Found  » (Non trouvé).



La figure 10 montre le source du programme BSEARCH. Le prototype RPG ILE pour
la fonction bsearch C est en A. La première ligne du code source précise que je
ferai référence à  la fonction bsearch sous le nom de FindIt dans le programme.
On notera que j’indique que cette fonction renvoie un pointeur en codant * (pour
pointeur) dans le champ type sur la carte D PR. Ceci est conforme au fait que
le prototype C (en A, figure 8) indique que la fonction bsearch renvoie un pointeur.
Les cinq paramètres que j’ai décrits précédemment sont ensuite définis dans les
cinq lignes suivantes du prototype en A. Il faut noter que le dernier paramètre
(CompFunc) est défini comme un type pointeur et utilise le mot-clé ProcPtr, ce
qui en fait un pointeur de procédure. Rappelons que ce paramètre est un pointeur
vers la fonction compare. En RPG ILE, un pointeur vers une fonction (ou sous-procédure,
dans ce cas) doit être défini comme un pointeur de procédure.



En B, on trouve le prototype de la fonction compare. Dans ce cas, j’appelle cette
procédure CompCity. Comme nous l’avons vu précédemment, cette procédure doit accepter
deux paramètres : un pointeur (LookFor) vers le champ contenant la valeur clé
et un pointeur (ArrElt) vers l’élément de tableau que l’on compare à  la valeur
clé. On notera que cette procédure est automatiquement invoquée (potentiellement
plusieurs fois) par la fonction bsearch, non par le programmeur. Rappelons que
la fonction compare est utilisée par bsearch pour apprendre le résultat d’une
comparaison que bsearch a décidé de faire.



Le tableau soumis à  recherche est appelé CityArr et défini en C. Le mot-clé Data
indique que c’est un tableau à  utiliser au moment de la compilation. Les données
du moment de compilation pour le tableau apparaissent en G.



La routine principale est en D. Le programme admet un paramètre unique appelé
CityLkup, défini par l’appelant. C’est le nom de la ville que l’on veut consulter
dans le tableau CityArr. L’instruction Eval invoque réellement la fonction bsearch.
Comme tous les paramètres sont transmis par valeur, ce peut être des expressions.
Cela me permet d’indiquer les cinq paramètres comme les valeurs de renvoi des
fonctions intégrées ILE RPG.



Rappelons que la documentation IBM indique que la valeur renvoyée sera NULL si
bsearch est incapable de trouver la valeur clé dans le tableau. L’instruction
If en D suivant l’instruction Eval teste cette condition. Si cette valeur renvoyée
est NULL (ou *Null en RPG ILE), le programme affiche le message  » Not Found « .
Sinon, il affiche le message  » Found « .



Voyons à  présent la fonction compare, qui est appelée CompCity et implémentée
en E. Le premier paramètre (LookFor) est un pointeur vers la valeur clé. On notera
qu’en F je définis un champ autonome basé appelé Key, où le pointeur de base est
ce premier paramètre. De même, comme le second paramètre est un pointeur vers
l’élément de tableau comparé, j’ai défini (en F) un champ basé appelé ArrElt,
dont le pointeur de base est le second paramètre. Par conséquent, dans cette sous-procédure,
chaque fois que je fais référence à  Key, je fais en réalité référence à  la valeur
clé dont l’adresse a été transmise comme premier paramètre vers cette sous-procédure.
De même, une référence à  ArrElt dans cette sous-procédure est en réalité une référence
à  l’élément de tableau dont l’adresse a été transmise comme le second paramètre
vers cette procédure.



Rappelons que cette procédure doit comparer les deux éléments et renvoyer un type
de donnée entier dont la valeur est négative, 0, ou positive, selon l’issue de
la comparaison. J’ai choisi ­1 et +1 comme valeurs de renvoi négative et positive.
Le bloc Select/EndSl met en oeuvre cette logique. Il met le champ RetVal à  ­1 quand
le champ clé est inférieur à  l’élément de tableau. Il le met à  0 quand le champ
clé est égal à  l’élément de tableau. Enfin, il le met à  +1 quand le champ clé
est supérieur à  l’élément de tableau. RetVal est donc positionné conformément
à  la documentation IBM en D, figure 8. Cette sous-procédure se termine en renvoyant
la valeur vers la fonction bsearch qu’il a invoquée.


Téléchargez gratuitement cette ressource

Sécurité Office 365 : 5 erreurs à ne pas commettre

Sécurité Office 365 : 5 erreurs à ne pas commettre

A l’heure où les données des solutions Microsoft de Digital Workplace 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 Microsoft 365, Exchange et Teams ? Découvrez les 5 erreurs à ne pas commettre et les bonnes pratiques recommandées par les Experts DIB France.

Tech - Par iTPro - Publié le 24 juin 2010