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
Préparer l’entreprise aux technologies interconnectées
Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Baromètre de la Transformation digitale 2024 en France
- Le secteur financier reste dans la ligne de mire des cyberattaquants
- CyberPatriot ®, le SOC de dernière génération de CHEOPS TECHNOLOGY
- L’IA comme levier d’évangélisation du COMEX à la cybersécurité
- Intégration et utilisation de l’IA en 3 conseils clés