Contrôle de l’accès utilisateur aux fichiers liés

employés
s’affichent dans un second sous-fichier (figure 7). Voyons certains aspects du
fonctionnement interne de ce programme.



La figure 8 montre des extraits importants tirés de la source pour le programme
DSPEMP. Notons tout d’abord que j’ai utilisé un curseur SQL pour l’accès séquentiel
au fichier employés. On ne peut pas utiliser les I/O natif standard pour accéder
à  une table contenant une ou plusieurs colonnes DataLink (pour plus d’informations
sur les curseurs SQL, voir les articles de Paul Conte et Richard Rubin indiqués
dans l’encadré  » Pour en savoir plus « ). Le curseur est déclaré en B, figure 8.
L’instruction Select du curseur inclut toutes les lignes et colonnes de la table
employés. Le curseur est ouvert en H. Les lignes provenant de la table de résultat
du curseur sont atteintes (c’est-à -dire lues séquentiellement) en G. Le curseur
est fermé en I.



Le curseur est utilisé pour peupler le sous-fichier illustré figure 6. Quand l’utilisateur
sélectionne un ou plusieurs enregistrements de sous-fichier et appuie sur Entrée,
le programme doit extraire les informations de données liées pour le(s) fichier(s)
Notes correspondant(s). Mais, auparavant, il doit obtenir le nom d’accès du fichier
avec le jeton correctement inséré dans le nom. Pour cela, le programme utilise
l’instruction Select Into montrée en F, figure 8. Préalablement à  cette instruction,
le programme émet un RPG ReadC (Read Next Changed Record) pour extraire un enregistrement
du sous-fichier sélectionné (non montré). La clause Where dans l’instruction Select
Into assure que nous sélectionnons la ligne que l’utilisateur a indiquée dans
la figure 6. Après la bonne exécution de cette instruction Select Into, la variable
de programme Path contient le nom d’accès avec le jeton inséré. Le programme peut
désormais ouvrir le fichier par un moyen quelconque.



Pour réaliser les I/O sur les fichiers liés, j’ai opté pour les API de
l’IFS



Pour réaliser les I/O sur les fichiers liés, j’ai opté pour les API de l’IFS telles
qu’elles sont expliquées dans le manuel IBM OS/400 UNIX-Type APIs V4R4 (SC41-5875-03).
En particulier, j’ai utilisé les API open(), read() et close(). Les prototypes
de ces trois API apparaissent en A sur la figure 8. La spécification de contrôle
H BndDir( ¢QC2LE¢ ) dans la première ligne de ce programme donne au programme
l’accès, au moment de la liaison, à  ces API.



L’open pour le fichier lié est en D dans la figure. Cette fonction open renvoie
un descripteur de fichier qui, à  l’instar d’un handle de fichier, doit être utilisé
chaque fois que le fichier est référencé dans les opérations d’I/O suivantes.
Notons que le programme passe le nom d’accès (jeton inclus) comme il a été reçu
dans l’instruction Select Into exécutée en F. Le programme passe également un
flag à  cette fonction, indiquant qu’il ouvre ce fichier pour un accès en lecture
seule.



Le Read du fichier lié apparaît en C. Le premier paramètre est le descripteur
de fichier qui a été renvoyé dans l’opération open. Le deuxième paramètre est
un pointeur vers une zone qui contiendra les données qu’il lit. Dans le cas présent,
je veux que la fonction Read stocke les données dans un champ appelé CurrChar.



Le dernier paramètre (1) ordonne à  la fonction Read de n’extraire qu’un caractère.
L’API Read() API permet de renvoyer plus d’un caractère, mais comme le fichier
est du type stream d’octets, le programme n’a aucun moyen de savoir où chaque
ligne de texte se termine. Il lit donc un caractère à  la fois, assemblant les
caractères dans une zone tampon (non montrée) jusqu’à  ce qu’il rencontre un caractère
retour chariot (X¢0D’) et un caractère saut de ligne (X¢25¢).



La fonction Read renvoie le nombre de caractères lus (dans ce programme, elle
ne lit qu’un caractère). Le programme déplace le nombre de caractères lus dans
un champ RPG appelé NumCharsRead. L’API Read() renvoie zéro lorsqu’on tente de
lire au-delà  de la fin du fichier. Si une erreur se produit, elle renvoie -1.
Je manque de place pour décrire entièrement ici la logique que le programme utilise
pour assembler les caractères dans une ligne de texte, et aussi pour décrire le
traitement des erreurs suivant ces API. Mais je montre le bloc Select/EndSl suivant
l’invocation ReadFile en C. Le code suivant (When NumCharsRead < *Zero) traite les conditions d'erreur. Le code suivant (When NumCharsRead = *Zero) traite les fins de fichier. Enfin, le code suivant (When NumCharsRead > *Zero) traite une
lecture réussie d’un seul caractère.



La fermeture du fichier lié apparaît en E. Là  encore, il faut passer le descripteur
de fichier à  la fonction Close.