> Tech > Le chemin de données ouvert (ODP, open data path)

Le chemin de données ouvert (ODP, open data path)

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

L’ODP est un objet temporaire qui contient des informations ponctuelles sur le fichier auquel on accède, pour le compte de votre requête HLL ou SQL.
Cette information change quand l’ODP est utilisé. Chaque job (ou session) a son propre jeu d’ODP. La plus forte dépense se produit quand l’ODP

Le chemin de données ouvert (ODP, open data path)

est créé, pas quand il est mis à jour.
Contrairement à une idée reçue, il y a un overhead d’exécution chaque fois qu’un programme est appelé. En effet, chaque programme doit être activé et le stockage doit être alloué, les méthodes d’accès existantes doivent être validées par rapport à la base de données (cela est fait pour RLA et SQL) et, finalement, l’ODP doit être créé. Un programme est non réentrant (par exemple, *INLR est activé (on) avant de revenir d’un programme RPG), il est désactivé quand il revient vers le programme appelant. La désactivation du programme se traduit par la suppression de tout ODP pour ce programme et par la libération du stockage interne. Au prochain appel du programme, ce processus se répètera. Ce mode d’utilisation des ressources système est très inefficace et peut se traduire par des temps d’exécution plus longs et par une diminution du débit global du système.

Dans les exemples de code précédents, vous avez peut-être remarqué que le *INLR est activé avant de revenir de ce programme.
L’équipe de programmation de ABC Corporation a décidé en toute connaissance de cause d’utiliser *INLR malgré la mise en garde à propos de l’overhead de performance. En effet, ces programmeurs ont constaté que s’ils exécutent une commande OVRDBF (Override Database File) pour passer d’un membre de bibliothèque ou de base de données à un autre, ils doivent s’assurer de la fermeture du fichier. Sinon, l’ODP reste connecté au fichier ou membre précédent. La présence de l’indicateur *INLR garantit que le fichier sera fermé. En outre, le programmeur n’a pas à se soucier du repositionnement des curseurs ou de la réinitialisation des variables du programme.

Le comportement normal de SQL (qu’il soit statique imbriqué, dynamique imbriqué, dynamique ou dynamique étendu) est de tenter de réutiliser un ODP existant après la seconde exécution de la même instruction SQL dans le même job. Dès lors qu’un ODP devient réutilisable, le plan associé à l’instruction SQL n’est plus validé dans le cadre de l’exécution du programme. Cette situation est souhaitable dans la plupart des environnements de traitement transactionnel à fort volume.

La figure 12 montre un fragment de journal de job relevé pendant le test du programme RPG SQL fonctionnant en mode débogage. Le message informatif SQL7912 est envoyé quand un « full open » se produit – c’est-à dire, quand un ODP est créé à partir de zéro. Le message informatif SQL7913 est envoyé quand l’ODP est supprimé (appelé aussi « hard close »). Le message informatif SQL7914 est envoyé quand l’ODP n’est pas supprimé. La prochaine exécution du programme se traduira par la réutilisation de l’ODP (message SQL7911).

On peut empêcher ce comportement. C’est d’ailleurs ce qui s’est produit chez ABC Corporation. Le programmeur de base de données SQL a compilé le module d’I/O SQL avec le paramètre de précompilateur CLOSQLCSR (Close SQL Cursor) réglé sur *ENDMOD. Par conséquent, l’ODP a été supprimé quand le programme appelant a repris la main. Le programmeur s’inquiétait du fait que l’ODP ne soit pas recréé quand une liste de bibliothèques était modifiée ou qu’une commande OVRDBF était émise et que l’ODP était déjà attaché à un fichier et à un membre (même problème que celui auquel les programmeurs RLA avaient été confrontés).

SQL reconnaît ces types de changements environnementaux après être passé en mode réutilisation d’ODP. Le fragment de journal de job de la figure 13 montre que l’ODP est supprimé à la prochaine exécution après émission d’une commande CHGCURLIB i5/OS. Dans ce cas, le programme a été en activité et avant la nième exécution, la liste de bibliothèques a été changée. DB2 reconnaît cela et supprime l’ODP existant (message SQL7918). Le texte de second niveau du message décrit la raison de la suppression (code 5).

Dans ce cas, DB2 a trouvé de multiples instances de EMP_TABLE dans plusieurs bibliothèques (schémas), ce qui a forcé la suppression de l’ODP. Cette application à la demande de la suppression de l’ODP est beaucoup moins coûteuse que la suppression de l’ODP après chaque utilisation dans chaque job utilisant ce programme – particulièrement si la liste de bibliothèques ne change jamais ou si un OVRDBF n’est jamais émis.

Une fois que l’équipe de programmation a compris ces différences entre SQL et RLA, elle a simplement recompilé le programme RPG SQL, en prenant la valeur par défaut *ENDACTGRP recommandée pour l’option CLOSQLCSR. Il en est résulté un énorme accroissement des performances se traduisant par une réduction des temps d’exécution batch.

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010