Comprendre les ouvertures de base de données

le contenu de la table.

Avant d’utiliser le point de sortie, il faut bien comprendre quand un « full open » a lieu. En effet, le timing de cet événement dépend de plusieurs conditions, y compris le genre d’accès à la base de données que vous demandez : accès RLA ou SQL.

Record Level Access. RLA (appelé souvent « I/O natif ») est la manière classique par laquelle les programmes évolués (HLL, high level language) du genre RPG et Cobol, accèdent au contenu des fichiers. Beaucoup de programmes utilisent encore aujourd’hui RLA pour accéder aux données. Le full open dans RLA se produit quand le programme émet l’opération ou la méthode open, pas pendant la tentative proprement dite d’accéder aux données (comme l’opération READ ou CHAIN).

Dans le cas d’un programme RPG utilisant RLA, les tables sont définies dans les F specs du programme. Le moment où l’open se produit varie selon que le mot-clé USROPN a été spécifié ou non dans la F-spec. Dans la négative, un full open implicite se produit au moment où le programme est invoqué initialement.

En revanche, si le mot-clé USROPN est spécifié dans la Fspec, le programme doit ouvrir explicitement la table en utilisant l’opération OPEN ou la fonction intégrée %OPEN. Dans l’un ou l’autre cas (open implicite ou explicite), la valeur que le programme RPG attribue à l’indicateur Last Record (LR) détermine le comportement d’ouverture de la table des appels suivants adressés à ce programme. Si LR est activé, les tables sont fermées avant que le programme ne se termine, et un full open se produit pendant chaque appel suivant adressé au programme. En revanche, si le programme n’active pas LR, toutes les tables sont laissées ouvertes pour les appels suivants adressés à ce programme, leur épargnant ainsi les full opens. Dans cette situation, l’ODP est maintenu et le programme se trouve dans ce qu’il est convenu d’appeler le mode réentrant.

Il existe un autre genre d’ouverture avec RLA : shared open, une technique permettant de partager l’ODP d’un fichier entre plusieurs programmes dans le même job ou la même étape de routage. Un programme émet le full open pour le fichier, et tous les autres programmes dans ce job peuvent utiliser le même ODP pour ce fichier, économisant ainsi des ressources système : CPU, mémoire et disque. Un shared open est contrôlé par le paramètre SHARE(*YES) dans les commandes override ou create file avant l’ouverture du fichier. Les shared opens sont couramment utilisés dans des applications en utilisant la commande OPNQRYRF.

SQL Access. Les programmes HLL et les interfaces à distance telles que ODBC, JDBC et ADO.NET peuvent utiliser SQL pour accéder aux tables. Bien entendu, il y aura ouverture quand l’instruction SQL OPEN sera utilisée sur un curseur. Des ouvertures moins évidentes ont lieu quand les instructions SELECT INTO, INSERT, DELETE et UPDATE sont exécutées. Ces instructions, comme toutes les instructions SQL, sont exécutées par le gestionnaire de base de données, lequel ouvre en interne les tables pour l’application.

Pendant l’exécution initiale du curseur Open ou d’une autre instruction SQL, le gestionnaire de base de données effectuera un full open. La table est fermée quand le curseur est fermé ou que l’instruction a fini de s’exécuter. Si la même instruction est exécutée une deuxième fois dans le même job ou connexion, le processus est répété et un autre full open se produit. Après cette deuxième exécution, le gestionnaire de base de données ne ferme pas réellement la table : elle reste ouverte pour d’autres exécutions de l’instruction dans le même job ou connexion.

Pendant la troisième exécution de l’instruction, le gestionnaire de base de données n’a pas à effectuer le full open car la table est déjà ouverte. C’est un pseudo open et l’instruction à ce moment-là est dans un état connu sous le nom de mode ODP reuse. Les pseudo opens présentent les mêmes caractéristiques et le même comportement que les shared opens en I/O natif.