J'ai utilisé une instruction SQL Create Table pour créer le fichier de test Master, constitué de 40 champs, y compris les types de données Integer, Decimal, Character, Character Varying et Date. Ce fichier possède une clé primaire associée à un chemin d'accès unique, constituée d'un seul champ Integer dénommé MasterId.
Fichiers et programmes de test

La longueur d’enregistrement allouée au fichier est de 1.320 octets et la longueur de sa mémoire-tampon est de 2.920 octets ; la différence entre la longueur allouée et la longueur de la mémoire-tampon résulte des champs caractères de longueur variable.
J’ai peuplé le fichier avec 109.698 enregistrements qui ont reçu des valeurs de clé pseudo-aléatoires et ont été écrits dans le fichier dans un ordre pseudo-aléatoire différent de celui des clés ; il n’y a ainsi aucun séquencement ou clustering physique des valeurs de clés dans le fichier. J’ai également utilisé un process pseudo-aléatoire pour définir la longueur des chaînes écrites dans les champs caractères de longueur variable. Dans certains cas, la chaîne dépassait la longueur allouée du champ et a été stockée en partie dans la zone de débordement du fichier. La taille totale du fichier était de 160.141.312 octets, suffisamment petite pour que tout le fichier tienne dans les pools de mémoire disponibles.
Pour tester l’accès à un fichier trié, j’ai dupliqué l’objet du fichier Master et ses données dans le fichier MasterX puis utilisé une commande RgzPfm (Reorganize Physical File Member) pour trier ce fichier d’après sa clé primaire MasterId.
Pour tester l’accès RPG à un sous-ensemble de champs, j’ai utilisé DDS pour créer deux fichiers logiques : un avec quatre champs provenant du fichier Master et un avec 10 champs. Les deux fichiers logiques partageaient le chemin d’accès par clé du fichier Master. Le fichier de quatre champs avait une longueur allouée et une longueur de mémoire-tampon de 22 octets ; le fichier de 10 champs, qui incluait un champ caractère de longueur variable, avait une longueur allouée de 335 octets et une longueur de mémoire-tampon de 1.135 octets.
J’ai écrit tous les programmes de test en RPG IV. J’ai utilisé les codes opération d’I/O intégrés (Read et Chain, par exemple) pour les tests " RPG " et les instructions SQL imbriquées (Fetch et Select, par exemple) pour les tests " SQL ". Les cartes F RPG n’incluaient pas un mot-clé Block (le blocage étant assuré par des commandes OvrDbf pendant l’exécution des tests). J’ai compilé tous les programmes avec l’optimisation complète. Les programmes SQL ont été précompilés en utilisant Commit(*None) et AlwBlk(*AllRead) sur la commande CrtSqlRpgI (Create SQL ILE RPG Object), qui permet à l’optimiseur de requêtes d’utiliser le blocage et les fichiers temporaires si nécessaire.
Quelques canevas SQL pour programmeurs RPG 1. lire un enregistrement spécifique sur clé Des variantes de ces techniques peuvent servir à d’autres besoins applicatifs. PC |
Téléchargez cette ressource

Rapport mondial 2025 sur la réponse à incident
Dans ce nouveau rapport, les experts de Palo Alto Networks, Unit 42 livrent la synthèse des attaques ayant le plus impacté l'activité des entreprises au niveau mondial. Quel est visage actuel de la réponse aux incidents ? Quelles sont les tendances majeures qui redessinent le champ des menaces ? Quels sont les défis auxquels doivent faire face les entreprises ? Découvrez les top priorités des équipes de sécurité en 2025.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Les risques liés à l’essor fulgurant de l’IA générative
- Pourquoi est-il temps de repenser la gestion des vulnérabilités ?
- Reporting RSE : un levier d’innovation !
- De la 5G à la 6G : la France se positionne pour dominer les réseaux du futur
- Datanexions, acteur clé de la transformation numérique data-centric
