Accès par clé RPG d’un fichier non trié

numbers) des enregistrements) pour demander chaque enregistrement
depuis son emplacement dans le fichier. Une fois que le RRN d’un enregistrement
est obtenu à  partir du chemin d’accès, les étapes permettant d’extraire les données
et de les présenter au programme sont à  peu près les mêmes que pour l’accès par
ordre d’arrivée.
Avec RPG, on peut utiliser une commande OvrDbf avec les paramètres NbrRcds et/ou
SeqOnly pour indiquer la taille de transfert et de blocage, mais il faut choisir
ces deux éléments avec prudence. La figure 6 présente les performances RPG sans
commande OvrDbf et avec un échantillon sélectionné de valeurs NbrRcds en même
temps qu’un paramètre SeqOnly(*No) pour empêcher le blocage des enregistrements
du programme. Ces tests ont tous été exécutés avec les pools de mémoire partagée
mis à  *Calc.

J’ai également testé diverses valeurs pour un paramètre SeqOnly(*Yes n) et constaté
des performances très inconstantes, allant d’environ 20.000 à  120.000 enregistrements
par minute, sans relation visible avec la valeur de SeqOnly. Il est intéressant
de noter que, dans ce cas particulier, j’ai obtenu de meilleures performances
en réglant les pools de mémoire sur *Fixed et en donnant à  NbrRcds et à  SeqOnly
des valeurs comprises entre 44 et 352 enregistrements. Le meilleur résultat a
été de 131.156 enregistrements par minute. De plus, je n’ai constaté aucune inconstance
des performances en utilisant SeqOnly(*Yes n) avec des pools de mémoire *Fixed.

Des résultats obtenus, on tire des enseignements importants pour cet accès séquentiel
avec clé d’un fichier non trié :

· Avec les pools de mémoire *Calc, évitez le blocage en utilisant SeqOnly(*No)
ou en définissant Block(*No) sur la carte F RPG pour le fichier.

· Quand la contention de mémoire est basse, considérez une valeur NbrRcds augmentant
la taille de transfert au-dessus de la valeur par défaut.

· Avec les pools de mémoire *Fixed, considérez une valeur SeqOnly(*Yes n) renvoyant
au moins un bloc de 32 Ko au programme (11 enregistrements pour ce fichier de
test, par exemple).

Nous avons là  un excellent ensemble de tests pour mettre en lumière un aspect
du système de mémoire virtuelle de l’AS/400, peut-être pas évident, mais important
pour optimiser les performances d’I/O. Rappelons que pour ces benchmarks, tout
le fichier peut tenir dans les pools de mémoire disponibles Par conséquent, quand
un bloc de données est transféré du disque en mémoire, il y reste jusqu’à  la fin
du test. Avec une taille de transfert de deux enregistrements ou plus, quand le
programme demande l’enregistrement pour une valeur de clé particulière, le transfert
extrait des enregistrements supplémentaires. Ainsi, avec une taille de transfert
de 26 Ko, 18 enregistrements environ sont extraits avec chaque requête. Quand
le programme demande les autres enregistrements dans ce bloc de transfert, aucune
I/O disque n’est requise. Le système de mémoire virtuelle trouve les enregistrements
déjà  présents en mémoire. Donc, à  condition que de gros blocs de transfert ne
soient pas remplacés en mémoire trop fréquemment (par des demandes de mémoire
d’autres travaux ou parce que le fichier est trop gros pour tenir en mémoire),
l’accès séquentiel avec clé d’un fichier non trié tire profit de grandes tailles
de transfert.