LES DONNÉES ET L'OS400. le SGBDR DB2/400

Transcription

1 OS LES DONNÉES ET L'OS400 le SGBDR DB2/400 Auteur : Dominique Vignez OS40004.DOC

2 DB2/400 les données et l'os400 2 Cette page est laissée intentionnellement blanche

3 DB2/400 les données et l'os400 3 Table des matières 1 Introduction Traitement des données par l'as Description des fichiers Description au niveau enregistrement Description au niveau champ types de données supportés Organisation de la Base de Données AS Notion de base de données Méthodes de description des données au système Outils d'aide à la gestion des descriptions de données Dictionnaire des données Fichier de références de zones Utilisation d Operation navigator Terminologie OS400 DDS Niveaux informations dans un membre source de description de données Créer un membre PF ou LF Syntaxe d'une ligne de spécification DDS OS400 IDDU SQL/ Description à l'aide de Query Manager Description des fichiers système Fichier QIDCTP Fichier QIDCTP Fichier QIDCTP Fichier QIDCTP Fichier QIDCTP Fichier QIDCTP Fichier QIDCTP Fichier QIDCTP Fichier QIDCTP Fichier QIDCTL Fichier QIDCTL Fichier QIDCTL Fichier QIDCTL Fichier QIDCTL Fichier QIDCTL Fichier QIDCTL SYSINDEXES SYSKEYS SYSCOLUMNS SYSTABLES SYSVIEWDEP SYSVIEWS...31

4 DB2/400 les données et l'os Évolutions relatives au support de DB2 en V3R1M Support de IFS (Integrated File System) Réorganisation des tables système QABDCCST QADBFCST QADBIFLD QADBKFLD QADBXRDBD QADBXREF QADBPKG QADBFDEP Support des contraintes d'intégrité référentielle Support des triggers ou déclencheurs Les messages escape du SGBD Procédures cataloguées Validation à deux phases ou two phases commit Les fichiers de l'os Types de fichiers Accès aux fichiers CONTRÔLE DES ACCÈS FICHIERS Open feedback area I/O feedback area Les fichiers de données Structure Description fichiers physiques Structure Mots clé Niveau fichier Niveau format d'enregistrement Niveau zone Niveau clé fichiers logiques Structure Logiques joints Conversions de type de données Mots clé Niveau fichier Niveau enregistrement Niveau joint Niveau champ Niveau clé Niveau sélection/omission Autres fonctions base de données National Language Support...62

5 DB2/400 les données et l'os Predictive Query Governor Amélioration des performances Bases de données distribuées Passerelles vers d'autres SGBDR Data Propagator Opticonnect Bases de données parallèles La base de données SMP (Symetric Multiprocessing Parallel) La base de données faiblement associée Sécurité des données La journalisation La protection des chemins d'accès par le système (SMAPP) Le contrôle de validation DASD de technologie RAID Limitations...67

6 DB2/400 les données et l'os400 6

7 DB2/400 les données et l'os Introduction De par son caractère intégré, situé pour partie au dessus du MI et pour partie à l'intérieur du SLIC, la base de données de l'as400 atteint un niveau d'efficacité plus important qu'une autre base de données qui serait construite au dessus du système d'exploitation. La base de données de l'as400 a été conçu pour le S38 dès 1975 par Perry Taylor. A cette époque E.F. Codd travaillait pour IBM sur un projet appelé System/R et avait décrit un système relationnel de table à deux dimensions, sur laquelle on pouvait réaliser quatre opérations (order, selection, projection, join). Perry Taylor entra en contact avec Codd pour lui faire part de ses propres travaux et lui demander d'unir leurs efforts. Mais Codd le pris de haut annonçant que les bases de données relationnelles ne pouvaient être conçues que pour les gros systèmes et qu'un petit système n'avait besoin que d'un tri et d'une fusion de fichiers. La première base de données relationnelle à être installée sur un ordinateur fut celle du S38 en 1978, mais sans l'opération join. Trois ans plus tard, la base de données du système/r fut commercialisée sous le nom de DB2 et comme elle possédait les quatre opérations, il fut décrété qu'elle était finalement la première base de données relationnelle au monde. Comme il n'existait pas d'interface standard aux bases de données relationnelles à l'époque où la base de données du système 38 a été lancée, il a fallu développer une interface native : les DDS. Les spécifications du langage SQL ne sont venues que plus tard et une décennie a été nécessaire à leur stabilisation. Ceci explique que les DDS sont livrées encore aujourd'hui en standard alors que le kit de développement SQL est fourni en option. Cette nécessité historique fait que longtemps le SQL a été moins performant et quasiment inutilisé sur AS400. La réécriture du SGBD DB2/400 avec la V3.R1. de l'os400 a gommé cette différence. DDS et SQL sont maintenant au même niveau de performances sur l'as Traitement des données par l'as400 L'AS400 est une machine conçue pour s'intégrer dans l'aua d'ibm (Architecture unifiée d'applications) et pouvant assurer la compatibilité avec la gamme 3X ou avec la gamme gros systèmes et même micro sous OS/2 ou AIX pour RS/6000. Sur une même machine il est donc possible de gérer les données de plusieurs façons suivant les finalités recherchées. Ainsi, si l'on utilise des programmes utilisateurs provenant d'un 3X ou des produits sous licence IBM ou si l'on utilise des programmes s'inscrivant dans l'aua comme CICS par CSP/AE (à partir de la version OS/ ), on ne décrira pas les données de la même manière et on ne les traitera pas non plus de la même manière.

8 DB2/400 les données et l'os Description des fichiers 3.1 Description au niveau enregistrement Elle correspond à l'utilisation traditionnelle sans base de données. Seule la longueur de l'enregistrement est décrite au système. Le système ne connaît rien des champs contenus dans le fichier. La description des champs n'étant donnée qu'à l'intérieur des programmes. Cette façon de procéder est appelée "fichiers à description interne". Dans ce cas les données sont strictement dépendantes des programmes. 3.2 Description au niveau champ Elle correspond à l'utilisation avec base de données déjà utilisée sur le système 38. L'ensemble des éléments à décrire pour un champs comprend : - le nom, - la longueur, - le type, - les domaines de validité, - un texte descriptif. Cette façon de procéder est appelée "fichiers à description externe". Dans ce cas les données sont indépendantes des programmes types de données supportés Le type de données est indiqué en colonne 35 d'une spécification de description de données (A) voir annexes les types possibles sont : - P numérique décimal packé, - S numérique décimal zoné, - B numérique binaire, - F numérique flottant, - A alphabétique, - H hexadécimal, - L date, - T heure, - Z horodatage. Si le type de données n'est pas explicitement indiqué le système attribuera par défaut le type A (alpha) si ne nombre de décimales (colonne 36,37) est blanc, ou packé si le nombre de décimales est de 0 à 31. Indiquer 0 décimale en colonnes désigne un entier pour des zones définies en packé, zoné ou binaire. Si le type est F (virgule flottante) il faut spécifier le mot clé FLTPCN pour indiquer la simple ou la double précision du nombre flottant.

9 DB2/400 les données et l'os400 9 Le type hexadécimal permet d'indiquer au système qu'il ne doit pas interpréter le contenu de ce champ et le restituer tel quel. Dans la plupart des cas un champ défini en hexadécimal sera traité sur les mêmes règles qu'un champ alpha. 4 Organisation de la Base de Données AS400 Sur AS400 il existe 4 méthodes pour décrire les données : - à l'aide de sources DDS suivis d'une compilation (CRTPF, CRTLF), - à l'aide de IDDU, - à l'aide de SQL, - à l'aide de Query Manager. Suivant la méthode utilisée l'environnement système et les possibilités sont différentes mais toujours complémentaires. 4.1 Notion de base de données Sur AS400 une base de données est un ensemble de fichiers physiques et logiques contenus dans une même bibliothèque. Conceptuellement une base de données ne peut pas contenir d'autres bases de données. L'arborescence est donc limitée à sa plus simple expression. Seule la base de données du système (QSYS) qui est la racine, peut contenir d'autres bases de données. Le gestionnaire système de la base données, n'a donc à gérer que deux niveaux hiérarchiques. Au niveau le plus bas (QSYS) le gestionnaire dispose de deux fichiers physiques. QADBXREF (description des fichiers) contenant un enregistrement de 127 octets pour chaque fichier existant collectant les renseignements suivants : - nom du fichier, - nom de la librairie, - nom du dictionnaire, - nom du propriétaire, - texte descriptif, - type de fichier (physique, logique, table, vue, index), - statuts de lien (Externe, Programme, sans), - type du dictionnaire (Iddu, Crtdtadct, Sql, Xmigration, - type fichier (Data, Source), - nombre de champs, - nombre de champs clé, - longueur d'enregistrement, - identificateur interne dans dictionnaire (n record).

10 DB2/400 les données et l'os QADBFDEP (relations entre les fichiers) contenant un enregistrement de 41 octets pour chaque fichier basé sur un autre. - nom du fichier de base, - librairie du fichier, - nom du fichier dépendant, - librairie du fichier dépendant, - type de dépendance (Données, Vue, Index). Deux fichiers logiques sont basés sur QADBXREF se sont QADBXFIL, QADBXDIC et deux fichiers logiques sont basés sur QADBFDEP se sont : QADBLDEP et QADBLDNC pour simplifier les accès. Lorsque l'on décrit les données avec la méthode des DDS, seule cette configuration est en oeuvre associée à la description des champs contenue dans le fichier lui même. 5 Méthodes de description des données au système Si vous désirez décrire un fichier uniquement au niveau enregistrement, vous pouvez utiliser le paramètre de longueur d'enregistrement (RCDLEN) en utilisant la commande de création de fichier physique CRTPF. Si vous désirez décrire un fichier au niveau champs, vous pouvez utiliser plusieurs méthodes : l'utilitaire IDDU (interactive data description utility), les commandes SQL/400, ou les DDS (data description specifications). Les DDS offrant le maximum des possibilités de descriptions offertes au programmeur, c'est souvent cette méthode que vous utiliserez. 5.1 Outils d'aide à la gestion des descriptions de données Afin d'éviter les doubles définitions de données et dans un souci de standardisation, il est possible d'utiliser soit un dictionnaire de données soit un fichier de références de zones Dictionnaire des données Un fichier à description interne peut être décrit dans un dictionnaire de données pour le détail du ou des formats d'enregistrements surtout si ce fichier doit être utilisé par QUERY/400, PCS/400 ou DFU. De même un fichier à description externe peut également être décrit dans un dictionnaire. Le système s'assurant que les deux définitions soient bien identiques Fichier de références de zones L'ensemble des détails de description des champs peut être contenu dans ce fichier, évitant ainsi au programmeur des redéfinitions longues et sources d'erreurs.

11 DB2/400 les données et l'os L'utilisation de ce fichier accroît la productivité du programmeur et garanti l'uniformité des descriptions de données d'un programmeur à l'autre. 5.2 Utilisation d Operation navigator Operation Navigator permet de gérer la base de données par interface graphique. Les requêtes SQL sont générées automatiquement par l interface. A partir de la V4.R4. c est l outil le plus puissant de l AS400 pour gérer les possibilités de DB2 Universal DataBase. 5.3 Terminologie Suivant la méthode employée les notions logiques de mêmes entités peuvent être nommées différemment. La liste suivante donnera les termes pour une organisation traditionnelle puis selon l'os400 puis selon SQL. répertoire librairie collection fichier fichier physique table index secondaire fichier logique vue enregistrement format rangée ou tupple item champs colonne ou attribut

12 DB2/400 les données et l'os Ces termes bien que regroupant des conceptions identiques ne sont pas simplement des homonymes mais bien des entités différentes qui ne peuvent être utilisées l'une pour l'autre. Ces parallèles ne sont faits que pour aider à la compréhension. Pour de plus amples informations sur ce sujet, consultez les brochures IBM programming data base guide, programming data management guide.

13 DB2/400 les données et l'os OS400 DDS Les fichiers à description externe peuvent être décrits en utilisant le langage de description de données. Il s'appelle : DDS : Data Description Spécification en anglais. SDD : Spécification de Description de Données en français. Il sert à décrire les données dans des membres source :. de Base de données : membres source PF et LF.. d'affichage : membres source DSPF.. d'impression : membres source PRTF.. de communications : membres source ICFF.... etc. Chaque ligne d'un membre de donnée = une spécification. Chaque spécification contient la lettre 'A' en colonne 6. L'utilisation des DDS vous permet d'intervenir dans les descriptions au niveau du champs, de l'enregistrement et du fichier. Ce n'est que par l'utilisation des DDS qu'il est possible de décrire les clés du chemin d'accès d'un fichier logique par exemple. Ceci contrairement à SQL qui vous permettra de décrire des vues.

14 DB2/400 les données et l'os La colonne 17 de la spécification A peut contenir : - R pour indiquer la description d'un enregistrement (Record), - K pour indiquer la description d'une zone clé, - J pour indiquer la description d'un joint, - S pour indiquer la description d'une sélection, - O pour indiquer la description d'une omission. Les colonnes 19 à 28 peuvent contenir un nom d'enregistrement ou un nom de champ. La colonne 29 peut contenir un "R" pour indiquer que la description du champ est à rechercher dans un autre fichier soit dans le fichier indiqué au mot clé REF, soit par rapport à une autre zone décrite précédemment au dans un autre fichier Indiqués au mot clé REFFLD. Les colonnes 30 à 34 peuvent contenir la longueur de la zone (cadrée à droite). La colonne 35 indique le type de données (voir ci-dessus types de données). Les colonnes peuvent contenir le nombre de décimales (cadrée à droite) pour la description d'une zone numérique. Un nombre de décimales égal à zéro indique une zone numérique entière. La colonne 38 décrit l'usage de la zone et n'est généralement pas utilisée pour les fichiers base de données. Les valeurs possibles sont : - I (Input) entrée, - O (Output) sortie, - B (Both) entrée sortie, - H (hidden) caché, - M (Message), - P (Program to system), - N (Neither) ni entrée ni sortie. Les colonnes 39 à 41 indiquent le no de ligne alors que les colonnes 42 à 44 indiquent le no de colonne. Ces informations ne sont utilisées que pour les fichiers écrans ou imprimantes et pas pour les fichiers base de données. Les colonnes 45 à 80 sont utilisées pour indiquer les mots clé. Voir ci-dessous les différents mots clé et leur niveau d'usage. Pour de plus amples informations sur les DDS consultez la brochure IBM programming data description specifications reference SC Niveaux informations dans un membre source de description de données

15 DB2/400 les données et l'os Un membre source de description de données contient des informations organisées en niveaux. Ces niveaux ont un ordre à respecter. Certains niveaux peuvent être ignorés s'ils ne sont d'aucune utilité dans un membre source. Un membre PF contient 4 niveaux : - informations de niveau fichier. - informations de niveau format d'enregistrement. - informations de niveau zone. - informations de niveau clé. Un membre LF contient 5 niveaux : - informations de niveau fichier. - informations de niveau format d'enregistrement. - informations de niveau zone. - informations de niveau clé. - informations de niveau sélection.

16 DB2/400 les données et l'os Créer un membre PF ou LF La création d'un membre source PF permet la création d'un fichier de données. 1) Avant de créer un membre PF, il faut connaître les informations suivantes sur le fichier : - le fichier répertoire qui contient la description des zones fichiers, - s'il y a présence de clé : unicité de la clé ou non, - le nom du format d'enregistrement à donner au fichier, - le nom des zones composant l'enregistrement, - le nom de ou des zone (s) composant la clé (optionnel ), - la ou les sélections à faire sur les données ( pour LF uniquement ). 2) Il faut organiser ces informations en niveaux : Au niveau fichier : - donner le nom du répertoire de description des zones, - dire si la clé est unique ou pas ( en cas de présence de clé), - donner autres infos. de niveau fichier. Au niveau format d'enregistrement : - donner le nom du format d'enregistrement, - donner autres infos. de niveau format d'enregistrement. Au niveau zone, pour chaque zone :

17 DB2/400 les données et l'os donner le nom de la zone, - si la zone est référencée : - dire si elle fait référence au répertoire cité au niveau fichier ou si elle fait référence à une autre zone, - si la zone n'est pas référencée : - donner sa longueur et son type; - donner infos complémentaires. au niveau zone. Au niveau clé : - donner la ou les zones composant la clé (cette ou ces zones doivent faire partie de l'enregistrement ), - donner autres infos. au niveau clé. Au niveau sélection omission : - décrire la/les sélections et/ou omissions de données. 3) Créer le membre PF ou LF sous PDM : Créer un nouveau membre de type PF ou LF. Pour saisir une ligne : insérer une ligne avec l'invite DP : IPDP (voir pages suivantes pour la syntaxe DDS) 4) Compiler le membre PF ou LF pour créer le fichier BD : utilisez l'option 14 de PDM (si besoin F4 pour les options et optimisations). Attention : il y a un ordre de création des différents fichiers de la BD. - créer d'abord le répertoire de données, - créer ensuite les fichiers Physiques, - créer enfin les fichiers Logiques Syntaxe d'une ligne de spécification DDS

18 DB2/400 les données et l'os400 18

19 DB2/400 les données et l'os400 19

20 DB2/400 les données et l'os OS400 IDDU Les fichiers physiques peuvent être décrits en utilisant IDDU. L'avantage d'utiliser IDDU est que c'est une méthode interactive avec accès par menus pour décrire les données. Il se peut également que des utilisateurs connaissant le système 36 en aient l'habitude et préfèrent cette méthode. De plus IDDU autorise la description de formats multiples en relation avec QUERY/400, PCS/AS/400 (PC Support) et DFU (data file utility). Si vous utilisez IDDU pour décrire vos fichiers, les définitions de fichiers deviennent des éléments d'un dictionnaire de données OS/400. Si vous désirez de plus amples informations à ce sujet consultez la brochure IBM IDDU user's guide. Lorsque l'on utilise la méthode IDDU, une base de données utilisateur, donc une librairie contient en plus des fichiers de données les objets suivants : - un dictionnaire de données (DTADCT) portant le nom de la base de données fichiers physiques qui sont : QIDCTP02 commentaires longs des fichiers, enregistrements et champs, QIDCTP10 descriptions des champs, QIDCTP20 descriptions des enregistrements, QIDCTP21 relations des champs et des enregistrements séquence des champs et mode de traitement, QIDCTP25 séquence et mode de traitement des enregistrements, QIDCTP30 descriptions des fichiers, QIDCTP31 relations des enregistrements et fichiers, QIDCTP51 zones clé d' un enregistrement, QIDCTP52 texte de la commande SQL ayant créée un enregistrement, QIDCTP53 relations entre un enregistrement et les fichiers physiques sur lesquels il est basé. - 7 fichiers logiques basés sur les précédents : QIDCTL76 liste des champs par alias basé sur P10, QIDCTL80 liste des champs par nom et par id interne de dictionnaire basé sur P10, QIDCTL81 liste des enr. basé sur P20, QIDCTL82 liste des fichiers basé sur P30, QIDCTL84 liste des enr. utilisant un champ basé sur P20, P21, QIDCTL86 liste des fichiers utilisant un enr. basé sur P30, P31, QIDCTL88 liste des fichiers utilisant un champ basé sur P20, P21, P30, P31. Ces objets sont nécessaires à l'utilitaire IDDU pour assurer sa fonction de description de données interactive. Mais IDDU n'est capable de créer que des fichiers physiques. Par contre il peut gérer les définitions de fichiers logiques. Un fichier créé par la méthode des DDS peut voir ses définitions gérées par IDDU à la condition que celles ci soient entrées dans le dictionnaire par la commande ADDDTADFN.

21 DB2/400 les données et l'os Néanmoins les fichiers partageants un chemin d'accès, ayant une séquence de classement alternée ou étant en union, les fichiers joints et les fichiers logiques en select ou en project ne sont pas gérables par IDDU.

22 DB2/400 les données et l'os SQL/400 Le langage de requête structuré SQL/400 peut être utilisé pour pour décrire une base de données AS/400. SQL/400 supporte les instructions pour décrire les champs d'une base de données, et pour créer les fichiers. Si l'application que vous développez doit s'inscrire dans un contexte de portabilité entre systèmes, il sera préférable de décrire vos données par SQL. Pour de plus amples informations à ce sujet, consultez la brochure IBM SQL/400 programmer's guide. Lorsque l'on utilise la méthode SQL, l'environnement s'enrichi encore et la base de données devient une collection par adjonction des éléments suivants : - QSQJRN journal associé au contrôle de validation SQL, - QSQJRN0001 récepteur de journal, - 8 fichiers logiques assurants la comptatibilité avec la norme SQL et dont les fonctions et contenus sont redondants avec ceux de IDDU, QSQTABLES basé sur P02 et P30; QSQCOLUMNS basé sur P10, P02, P20, P30, P31, QADBXREF; SYSCOLUMNS mêmes bases que le précédent; SYSINDEXES basé sur P30, QADBXREF, QADBFDEP; SYSKEYS basé sur P02, P10, P20, P51, QADBXREF; SYSTABLES basé sur P30, QADBXREF; SYSVIEWDEP basé sur P30, QADBXREF, QADBFDEP; SYSVIEW basé sur P30, P52, QADBXREF. Cette configuration est nécessaire pour créer des tables, des vues, des enregistrements par SQL. Mais pour gérer les données en lecture, en mise à jour ou en ajout à l'aide de SQL, il n'est pas indispensable que ces dernières soient incluses dans une collection. SQL400 est capable de gérer les données de l'as400 quelque soit leur mode de définition. 9 Description à l'aide de Query Manager Query Manager est un outil offrant une interface utilisateur pour utiliser le langage SQL. Il offre les mêmes possibilités que IDDU et SQL réunis, sans avoir recours aux fichiers systèmes. Par contre et s'en est la contrepartie, il est un peu plus lent d'exécution car chaque information doit faire l'objet d'un traitement pour être accessible au lieu d'avoir à effectuer une simple lecture de fichier. L'accès à Query Manager se fait grâce à la commande STRQM (démarrer Query Manager). En choisissant le choix 3 (gestion des tables QM) du menu qui s'affiche, une fenêtre permet d'indiquer la collection ou la bibliothèque sur laquelle on désire travailler.

23 DB2/400 les données et l'os L'affichage d'un choix de bibliothèque dans une liste est possible par l'intermédiaire de la touche F4. Il est possible ensuite de créer un fichier physique par l'option 1 (création de table).

24 DB2/400 les données et l'os Description des fichiers système 10.1 Fichier QIDCTP10 Longueur d'enregistrement : 535 octets nom externe du champ id interne du champ flag interne de delete fonction de création date de création heure de création id créateur date dernière modification heure dernière modification id dernier modifieur type général de donnée (1=char, 2=numérique) type détail de donnée majuscule par défaut longueur externe longueur interne nbre de décimales type de donnée SQL longueur SQL précision SQL valeur nulle possible (Y=oui, N=non) code d' édition séparateur de date et heure symbole de point décimal séparateur de milliers apparition du signe négatif signe négatif gauche signe négatif droit impression de la valeur zéro remplacement des zéros non significatifs remplacement de la valeur zéro option d' affichage des zéros négatifs affichage du symbole monétaire symbole monétaire gauche symbole monétaire droit mot d' édition longueur entête 1 de champ entête 1 de champ longueur entête 2 de champ entête 2 de champ longueur entête 3 de champ entête 3 de champ nom alias 10.2 Fichier QIDCTP20 Longueur d' enregistrement 123 octets

25 DB2/400 les données et l'os nom externe de l'enregistrement id interne de l' enregistrement flag interne de delete texte descriptif fonction de création date de création heure de création id du créateur date de dernière modif heure de dernière modif id du dernier modificateur code de révision du fichier physique 21 code de révision du fichier physique 25 réserve reserve 10.3 Fichier QIDCTP21 Longueur d' enregistrement 36 octets id interne d' enregistrement code de révision interne id interne de champ type de fichier (D=dbase) séquence relative de sortie séquence relative d' entrée usage du champ modifiable par SQL (Y=oui, N=non) n de référence de joint 10.4 Fichier QIDCTP25 Longueur d' enregistrement 36 octets id interne d' enregistrement code de révision interne id interne de champ n relatif de séquence type de fichier (D=dbase) position relative dans le champ opérateur de comparaison (EQ, NE, ZN, NZ, DG, ND) valeur test id enregistrement continuation et/ou (1=and, 2=or) 10.5 Fichier QIDCTP30 Longueur d' enregistrement 134 octets nom externe du fichier id interne du fichier flag interne de delete texte descriptif date de création heure de création id du créateur

26 DB2/400 les données et l'os date dernière modif heure dernière modif id du dernier modificateur type de fichier (1=physique, 2=logique) accès base de données (1=séquentiel, 2=par clés) type de joint (1=inner join, 2=left outer join) vérification SQL (Y=oui, N=non) clés en double (D=oui, U=non) séquence des clés en double (F=fifo, L=lifo) code de révision fichier physique 31 code de révision fichier physique 51 code de révision fichier physique 52 code de révision fichier physique 53 réserve réserve réserve définition fichier SQL 10.6 Fichier QIDCTP31 Longueur d'enregistrement 27 octets id interne fichier code révision interne id interne d' enregistrement N de séquence relatif 10.7 Fichier QIDCTP51 longueur d' enregistrement 40 octets id interne fichier code de révision interne id interne d' enregistrement id interne de champ n de séquence relatif ordre de tri de la clé (A=ascendant, D=descendant) attribut de clé (S=signée, U=non signée, A=alpha, D, Z) 10.8 Fichier QIDCTP52 Longueur d' enregistrement 86 octets id interne de fichier code de révision interne n de séquence relatif texte de la commande SQL de création 10.9 Fichier QIDCTP53 Longueur d' enregistrement 60 octets id interne fichier code de révision interne id interne d' enregistrement nom du fichier de base nom de la librairie du fichier de base

27 DB2/400 les données et l'os id interne du fichier physique de base n de séquence relatif séquence de référence de joint (0=logique) Fichier QIDCTL76 Vue logique de QIDCTP10 longueur enr. 30 octets, longueur clé 30 octets clé : Q76GUA Fichier QIDCTL80 Index de QIDCTP10 longueur enr. 535 octets, longueur clé 21 octets clé : Q10DEN,Q10IDI nom externe zone, id interne Fichier QIDCTL81 Index de QIDCTP20 longueur enr. 123 octets, longueur clé 21 octets clé : Q20REN,Q20IRI nom externe enr., id interne Fichier QIDCTL82 Index de QIDCTP30 longueur enr. 134 octets, longueur clé 21 octets clé : Q30FEN,Q30IFI nom externe fichier, id interne Fichier QIDCTL84 Vue jointe sur QIDCTP21/QIDCTP20 longueur enr. 101 octets longueur clé 11 octets clé : Q84IDI joint : QIDCTP21/Q21IRI QIDCTP20/Q20IRI id champ interne id enr. interne code révision interne code révision P25 séquence de sortie relative nom enr. externe date création heure création Fichier QIDCTL86 Vue jointe de QIDCTP31/QIDCTP30 longueur enr. 105 octets longueur clé 11 octets clé : Q86IRI joint : QIDCTP31/Q31IFI -> QIDCTP30/Q30IFI id enr. interne id fichier interne code révision interne

28 DB2/400 les données et l'os code révision P51 code révision P52 code révision P53 n séquence relatif Type fichier nom fichier externe texte descriptif date création heure création Fichier QIDCTL88 Vue jointe de QIDCTP21/QIDCTP20/QIDCTP31/QIDCTP30 longueur enr. 98 octets longueur clé 11 octets clé : Q88IDI joint : QIDCTP21/Q21IRI QIDCTP20/Q20IRI QIDCTP31/Q31IRI QIDCTP31/Q31IFI QIDCTP30/Q30IFI QIDCTP31/Q31R31 QIDCTP30/Q30R31 id champ interne id fichier interne code révision interne type fichier type de fichier base de données nom fichier externe texte descriptif date création heure création SYSINDEXES Cette vue logique contient un enregistrement pour chaque index de la base de données. NAME char(10) nom de l'index CREATOR char(10) propriétaire de l' index TBNAME char(10) nom du fichier physique TBCREATOR char(10) propriétaire du fichier physique TBDBNAME char(10) nom de la librairie du fichier physique UNIQUERULE char(1) clés en double autorisées D=oui (duplicates) U=non (unallowed) COLCOUNT integer nombre de champs dans la clé DBNAME char(10) nom de la lbrairie contenant l'index SYSKEYS Cette vue logique contient un enregistrement pour chaque champs contenu dans un index. IXNAME char(10) nom de l'index IXCREATOR char(10) propriétaire de l' index COLNAME char(10) nom du champs contenu dans l' index COLNO integer n d'ordre du champs dans l'enregistrement COLSEQ integer n d'ordre du champs dans la clé

29 DB2/400 les données et l'os ORDERING char(1) sens du tri du champs dans la clé A=ascendant D=descendant SYSCOLUMNS Cette vue logique contient un enregistrement pour chaque champs de chaque fichier logique et physique. NAME char(10) nom du champs TBNAME char(10) nom du fichier contenant le champs TBCREATO char(10) propriétaire du fichier R COLNO smallint n d'ordre du champs dans le fichier COLTYPE char(8) type de donnée INTEGER entier long SMALLINT entier court FLOAT nombre flottant CHAR caractère DECIMAL décimal packé NUMERIC décimal zoné LENGHT smallint longueur ou précision 4 bytes integer 2 " smallint 8 " float,float(n) n=25 à 53 ou double précision 4 bytes float(n) n = 1 à 24, réel longueur de la chaîne char nombre de digits decimal nombre de digits numeric SCALE smallint échelle de donnée numérique (zéro si non decimal, numeric ou non nul precision binaire) NULLS char(1) N=non, Y=oui le champs peut-il contenir une valeur nulle UPDATES char(1) N,Y le champs peut-il être modifié REMARKS char(254) commentaires DEFAULT char(1) N,Y si le champs a une valeur par défaut LABEL char(30) entête de colonne STORAGE smallint besoin en espace mémoire pour le stockage du champs idem définition de lenght sauf pour decimal = (nbre digits / 2) + 1 PRECISION smallint précision d'un champs numeric (Zéro si non numeric) SYSTABLES Cette vue logique contient un enregistrement pour chaque fichier physique ou logique de la base de données. NAME char(10) nom du fichier logique ou physique CREATOR char(10) propriétaire du fichier TYPE char(1) type de fichier L=fichier Logique

30 DB2/400 les données et l'os P=fichier Physique T=Table (SQL) V=Vue (SQL) COLCOUNT smallint nombre de champs du fichier RECLENGHT smallint longueur des enregistrements LABEL char(30) chaîne accessible par ordre SQL LABEL ON REMARKS char(254) commentaire DBNAME char(10) nom de la librairie contenant le fichier 10.22

31 DB2/400 les données et l'os SYSVIEWDEP Cette vue enregistre les dépendances des vues logiques sur les fichiers physiques. DNAME char(10) nom du fichier logique DCREATOR char(10) propriétaire de la vue BNAME char(10) nom du fichier physique BCREATOR char(10) nom du propriétaire du fichier physique BDBNAME char(10) nom de la librairie du fichier physique BTYPE char( 1) type de l'objet sur lequel la vue porte T=fichier physique V=vue logique SYSVIEWS Cette vue contient un ou plusieurs enregistrements pour chaque vue logique de la base de données. Chaque enregistrement contient les 70 premiers caractères de la commande de création de la vue. NAME char(10) nom du fichier logique CREATOR char(10) propriétaire de la vue SEQNO integer n d'ordre d'enregistrement dans la vue le premier étant 1 CHECK char(1) inutilisé sur AS400, présent pour assurer la compatibilité avec la norme SQL TEXT char(70) début de l'ordre SQL de création de la vue.

32 DB2/400 les données et l'os Évolutions relatives au support de DB2 en V3R1M Support de IFS (Integrated File System) IFS est une structure système qui permet à l'as400 de supporter simultanément : - un système de fichiers micro, - un système de fichiers Unix, - le système des bibliothèques de l'os400, - le système de dossiers de bureau, - des systèmes de fichier utilisateur personnalisés. Racine dossiers partagés QDLS DB2 POSIX QSYS QOpenSys Unix QLANSrv LAN server QFileSrvr.400 QOPT ToTo QIWSFLR2 Myfolder LIB usr Home QPWXCWN Windows Serv1 serveur optique rep1 FILE bin etc serv2 serveur Myrep Mydoc Serv2 optique rep2 MEMBER MEMBER Serv1 QPWXCRM Rumba QPWXCPC 5250 fichier fichier 11.2 Réorganisation des tables système Pour supporter le niveau 2 de DRDA, les tables système de l'os400 ont été réorganisées. Ainsi les tables SQL ne sont plus dans chaque collection mais dans QSYS. De plus un certain nombre de tables supplémentaires ont été ajoutées nous trouvons maintenant : 11.3 QABDCCST contient les informations relatives aux contraintes de niveau zone, comme nom de la zone, position dans la clé, QADBFCST contient les informations relatives aux contraintes de niveau fichier, comme le nom de la contrainte, le nom du fichier,...

33 DB2/400 les données et l'os QADBIFLD contient les informations relatives aux zones, comme type, longueur, etc QADBKFLD contient les informations relatives aux clés des chemins d'accès, comme nom de la zone, sens du tri, QADBXRDBD contient les informations relatives au répertoire de la base de données répartie, comme les noms des lieux éloignés, les ID d'echange de réseau, QADBXREF contenu et usage identique à la V2R3M0 ou V3R0M QADBPKG contient les informations relatives au packages SQL QADBFDEP contenu et usage identique à la V2R3M0 ou V3R0M5. D'autre part, les tables sytème SQL sont en réalité stockées dans QSYS2, leur nombre a également augmenté. Nom de catalogue SQL SYSCOLUMNS SYSCST SYSCSTCOL SYSCSTDEP SYSINDEXES SYSKEYS SYSKEYCST SYSPACKAGE SYSREFCST SYSTABLES SYSVIEW SYSVIEWDEP contient les infos concernant attributs de colonnes toutes les contraintes colonnes référencées dans une contrainte dépendances des contraintes sur les tables index index, clés d'index clés uniques, primaires et étrangères packages contraintes d'intégrité référentielle tables et vues définitions de vues dépendances des vues sur les tables Support des contraintes d'intégrité référentielle L'intégrité référentielle permet de gérer l'intégrité de la cohérence de la base de données à l'extérieur des programmes. C'est un progrès considérable par rapport à la base de données version Mais il y a un revers. Tout système applicatif possédant des fichiers et existant sur l'as400 n'est pas nécessairement normalisé. C'est à dire que souvent la base de données applicative n'est en réalité pas une vraie base de données. C'est notamment souvent le cas dans des applications qui ont été développées à l'origine sur un système 36.

34 DB2/400 les données et l'os Pour mettre en oeuvre l'intégrité référentielle, il est indispensable, que la base de données satisfasse aux règles des formes normales. Si ce n'est pas le cas, mieux vaut rester en l'état. Si, donc votre base de données est normalisée (vous avez donc utilisé MERISE pour la concevoir), vos programmes vont se trouver alégés d'un grand nombre de lignes de code maintenant inutiles. Avec l'intégrité référentielle, le gestionnaire de base de données peut seul et automatiquement géré les relations entre un fichier père et un fichier fils. La règle est que toute clé étrangère non nulle doit obligatoirement avoir son équivalent en clé primaire dans le fichier père. Autrement dit : il ne peut exister d'enregistrement commande dont le no de client ne serait pas une valeur d'une clé du fichier client. La commande CL ADDPFCST permet d'ajouter une contrainte à un fichier physique, de même que la commande SQL CREATE ALTER TABLE. Le fichier physique doit être mono membre. Il est donc impossible de mettre une contrainte sur un fichier multi membres. La contrainte se définie sur le fichier dépendant donc le fichier fils. Les contrôles sont soit implicites (automatiques) en cas de création ou de mise à jour de clé associée, soit explicites en cas de suppression. Il faut alors indiquer la règle de mise en oeuvre au paramètre DLTRULE. Les valeurs possibles sont : - *NOACTION suppression d'un record dans le père interdit si au moins un record du fils fait référence à cette clé. - *RESTRICT idem *noaction mais contrôle immédiat avant la suppression du père. - *CASCADE lorsqu'un record du père est supprimé, tous les records du fils contenant la même valeur de clé sont supprimés. - *SETNULL lorsqu'un record du père est supprimé, tous les records du fils sont mis à jour avec la valeur nulle à condition que cette valeur soit admise dans la description du fils. - *SETDEFAULT idem *SETNULL mais c'est la valeur par défaut définie dans le fils qui est utilisée. La différence entre *NOACTION et *RESTRICT est subtile mais importante. Si vous utilisez *NOACTION la journalisation est obligatoire. En effet toutes les mises à jour et suppressions seront effectuées avant que la contrainte soit lancée. Au cas ou un message d'erreur survient (le message ESCAPE est le moyen de communication entre le SGBD et votre programme) vous devez invalider les mises à jour. Or sans la possibilité du ROLLBACK c'est une opération périlleuse. Si par contre vous utilisez *RESTRICT, la vérification est lancée avant les mises à jour et le message intervient dans votre programme RPG sans que vous ayez à faire une mise à jour arrière. *RESTRICT donne donc de meilleures performances et doit être préféré à *NOACTION qui est pourtant la valeur par défaut du paramètre Support des triggers ou déclencheurs

35 DB2/400 les données et l'os Sur AS400 le déclencheur et le programme déclenché s'appellent tous deux trigger, d'où une confusion possible. Un trigger est un call automatique d'un programme écrit dans n'importe quel langage disponible sur l'as400 et dont le contenu et l'action est entièrement laissé à la discrétion du programmeur. il y a également des règles (rules) pour l'ajout, la mise à jour ou la suppression d'enregistrement (les triggers de zone ne sont pour l'instant pas disponibles sur AS400). Généralement un trigger de record est utilisé pour faire les contrôles de zones du record. Ainsi vos programmes se trouvent déchargés du contrôle des zones qui est laissé à la charge du SGBD. Ici encore le moyen de communication entre votre programme RPG et le SGBD est le message de type *ESCAPE. La commande ADDPFTRG permet d'ajouter un trigger à un fichier physique. Le SQL de l'as400 ne supporte pas pour le moment et ce au moins jusqu'en 1996 d'ordre pour les triggers et ce en attente d'une normalisation devant être effective avec la norme SQL3. Néanmoins la fonction trigger est très riche et permet de définir pour un seul record un trigger avant et après création, mise à jour et suppression. Six triggers différents peuvent donc être déclenchés pour un même record. Le programme déclenché a obligatoirement deux paramètres d'entrée qui sont une structure et la longueur de la structure.le dessin de la structure est : - nom du fichier (fichier, bibliothèque, membre) - type d'opération (création, mise à jour, suppression) - moment de l'appel (avant, après) - niveau de verrouillage - pointeur position et longueur (dans la structure) du buffer avant l'opération - pointeur position et longueur (dans la structure) du buffer après l'opération - valeurs du buffer avant - valeurs du buffer après un exemple de description de structure est disponible dans le membre LIBUXX/XXX,XXXCITRG en RPGIII et dans LIBUXX/XXXX, XXXXCITRG pour RPG IV Les messages escape du SGBD En cas de violation de l'intégrité référentielle, les messages suivants sont émis : - CPF502D violation de CIR sur le membre &4 en ajout dans un fichier fils sans correspodance dans le fichier père. - CPF503A violation de CIR sur le membre &4 en suppression du fichier père alors qu'il existe des records du fichier fils faisant référence à cette valeur de clé étrangère. - CPF502E enregistrement verrouillé, la CIR ne peut être lancée. - CPF523B erreur de CIR lors du traitement du membre &4 impossibilité système.

36 DB2/400 les données et l'os CPF523C erreur dans le journal d'intégrité référentielle. les règles demandent un contrôle de validation, mais la journalisation n'est pas démarrée ou les récepteurs de journaux des deux fichiers sont différents. De plus RPGIV ILE envoie les messages suivants : - RNQ1022 (*inquiry) et RNX1022 (*escape) correspondant aux messages CPF502D et CPF503A. - RNQ1299 (*inquiry) et RNX1299 (*escape) correspondant aux messages CPF523C et CPF523B. Il est donc capital de savoir gérer les messages escape en RPG grâce aux APIs de messages Procédures cataloguées Une implémentation de SQL pour mise à niveau avec SQL2 permet à DB2/400 de mettre en oeuvre les procédures cataloguées. La syntaxe SQL est : EXEC SQL DECLARE nomdeprogramme PROCEDURE (:parm1 IN CHAR(10) :parm2 IN DECIMAL (5,2)) EXTERNAL NAME nomlib/nomde programme LANGUAGE RPG END-EXEC. EXEC SQL CALL nomdeprogramme (:parm1, :parm2) END-EXEC. Il est ainsi possible d'appeler dans le SQL un programme écrit dans n'importe quel langage disponible sur l'as400 avec passage de paramètres Validation à deux phases ou two phases commit DB2/400 supporte le niveau 2 de DRDA et assure automatiquement la gestion des commit et roll back sur des bases de données réparties même en cas de rupture du réseau.

37 DB2/400 les données et l'os Les fichiers de l'os Types de fichiers L'OS400 supporte 4 types de fichiers. - fichiers de données (physiques ou logiques) PF LF, - fichiers écrans DSPF, - fichiers imprimantes PRTF, - fichiers de communications ICFF. Attention : seuls les PF contiennent des datas, les LF contiennent les clés de recherche et les DSPF, PRTF, ICFF ne contiennent que des descriptions. Fichier PF comportant les données. Contient 3 parties : Fichier LF : Logical File Fichier BD dépendant d'un PF ou de plusieurs PF (max. 32) et servant à créer : - un index sur les données du PF : un chemin d'accès aux données du PF. - un classement des données du PF : un tri pour une lecture séquentielle. - une sélection des données du PF : une vue sélective des données. - un regroupement de données de plusieurs PF dans un même fichier : logique joint. Contient 2 parties : ( pas de données dans un LF )

38 DB2/400 les données et l'os PF LF Puisque manipulés par l'os400 les fichiers sont des objets. En tant que tels ils doivent avoir une description, contenue dans un membre source d'un fichier source. Cette description doit ensuite être compilée soit par l'option 14 de PDM, soit par la commande CRTxF (x étant le type de fichier) pour que le fichier existe sur le disque. Au niveau du système, il existe en réalité plusieurs objets qui ne sont vus par l'utilisateur que comme un objet unique se sont : - les data spaces qui contiennent les datas, les enregistrements base de données. C'est que que nous pouvons appeler les membres. Cette définition nous permet de comprendre qu'un membre se comporte au moment des accès comme un fichier à part entière avec ouverture, début, fin, fermeture. C'est la commande OVRDBF qui permet d'accéder aux différents membres donc aux différents data spaces du même fichier. dans un data space les enregistrements sont rangés par ordre d'arrivée. - les index de data space qui permettent d'ordonner les enregistrements de data space autrement que dans l'ordre d'arrivée. Le mécanisme d'ordonnancement des enregistrements est basé sur un algorithme d'arborescence dichotomique basale. C'est ce qu'on appelle en OS400 les chemins d'accès. - les curseurs sont des mécanismes de visualisation des données. Ils contiennent les mécanismes de sélection et d'omission. C'est ce qui sert de base à la fonction OPNQRYF de l'os400 ou à l'ouverture avec sélection dynamique. Il est possible dans ces curseurs de réaliser des fonctions de mapping qui permettent de voir les données sous d'autres formats que ceux stockés ou de créer des zones résultantes d'opérations sur des zones existantes. Les ordres OPEN et CLOSE couramment utilisés en HLL déclenchent les instructions MI ACTIVATE CURSOR et DEACTIVATE CURSOR 12.3 Accès aux fichiers L'OS400 considère tous ses périphériques (devices) comme des périphériques "bloc". C'est à dire qu'il ne converse avec eux que par paquets d'octets et non octet par octet. Ainsi sur un

39 DB2/400 les données et l'os écran par exemple il n'est pas possible d'adresser directement une ligne colonne et d'y inscrire un caractère. On ne pourra écrire ou lire sur l'écran que la totalité de cet écran. De même dans un fichier de données, on ne pourra accéder qu'à un enregistrement et pas à un caractère unique. L'accès physique dépend avant tout de la capacité d'entrée sortie de chaque appareil. Dans la réalité, un lecteur de diskette pourra lire ou écrire 128, 256, 512 octets à la fois. Un lecteur de disque dur pourra accéder à 512, 1024, 2048, 4096 octets à la fois. Un contrôleur d'écran pourra gérer 1920 ou 2000 octets à la fois. Les lectures et écritures se feront par block du nombre d'octets gérables par l'appareil considéré. Pourtant il arrive souvent qu'on ne désire pas accéder à un nombre aussi important d'octets. Il y a donc un accès logique pour l'utilisateur qui est différent de l'accès physique de la machine. Il faut donc utiliser un intermédiaire qui permettra le découpage logique des données physiquement présentes. Cet intermédiaire est appelé un tampon (buffer). Les données en entrée ou en sortie seront stockées dans ce buffer en attendant que le block soit complet pour être effectivement échangé avec l'appareil. Le terme de buffer est employé au niveau physique et au niveau logique. Par exemple, la taille du buffer physique du disque peut être de 4096 octets et la taille du buffer logique du fichier à traiter peut être de 128 octets. Lorsque l'on désirera lire un enregistrement de 128 octets, on accédera en réalité à 32 enregistrements de ce fichier sur le disque. Si on réécrit le premier enregistrement lu, il n'y aura pas d'écriture physique sur le disque mais seulement dans le buffer physique. Ce qui est beaucoup plus rapide car ce sont seulement des transferts en mémoire. Si la lecture suivante fait appel à un des 31 autres enregistrements contenus dans le buffer physique, il n' y aura pas d'accès disque en lecture. Il n'y aura que transfert mémoire de l'enregistrement contenu dans le buffer physi que dans le buffer logique. Par contre si le 2 ème enregistrement demandé n'est pas dans les 31 disponibles, il y aura d' abord écriture du buffer physique sur le disque puis lecture d'un autre groupe de 32 enregistrements. Il faut donc décrire au système la taille du buffer logique du fichier que l'on désire utiliser, pour permettre les accès. Sur AS400 cette opération s'appelle DDS (data description specification). Les descriptions de fichiers seront entrées dans des spécifications sources de type A dont vous pouvez voir un exemple en annexes CONTRÔLE DES ACCÈS FICHIERS D'une façon générale le contrôle des accès aux fichiers est laissé à la charge du système d'exploitation. Celui-ci ne communiquant aux programmes qui désirent accéder à ces fichiers que des codes retour renseignant sur l'issue de la dernière opération effectuée (opération

40 DB2/400 les données et l'os réussie ou non et si non pour quel motif. L'OS/400 donne au programmeur la possibilité d'accéder à de nombreuses informations sur les fichiers accèdés. Deux zones de contrôle fichier sont disponibles, après une opération réussie d'ouverture sur un fichier. Il s'agit de l' open feedback area et de l'i/o feedback area. Ces zones de contrôle peuvent se révéler très utiles lorsqu' une erreur se produit sur un fichier Open feedback area Cette zone contient des informations d'ordre général sur le fichier comme son nom, la librairie, le type etc I/O feedback area Cette zone est découpée en deux parties. La première commune à tous les types de fichiers d'une longueur de 143 octets et donnant des renseignements comme des compteurs d'opérations d'entrée sortie par type d'opération, la nature de l'opération en cours, le nom du format d'enregistrement en cours, le type de périphérique utilisé, etc... La deuxième étant en fonction du type de fichier. Une description détaillée des différentes I/O feedback est donnée dans des membres de LIBUXX/YYY,YYYMIxF (x =G[LF],.=D[DSPF], =P[PRTF]).

41 DB2/400 les données et l'os Les fichiers de données 13.1 Structure La structure des fichiers de données peut être shématisée selon l'exemple suivant : 14 Description Une description de spécifications de données est enregistrée dans un fichier source. Les zones décrites dans une DDS sont les plus petits éléments physiques et logiques accessibles par l'os400. Il n'est pas possible d'appliquer un tampon logique différent du tampon physique sur une zone de la base de données AS400. Un découpage logique d'une zone de la base de données ne sera possible qu'à l'intérieur d'un programme par l'intermédiaire d'une structure de données. La description externe des fichiers, garantie l'indépendance des données et des programmes. En effet la description est identique quelque soit le langage utilisé dans les programmes. Il existe 4 niveaux logiques de description des fichiers : - niveau fichier (file), - niveau format ou enregistrement (record), - niveau zone ou champs (field), - niveau clé (key), Pour chaque niveau il existe des mots clé spécifiques qui permettent d'apporter des précisions sur la description fichiers physiques Le fichier physique de données est le type d'objet OS400 qui contient effectivement les données utilisateurs. Nous verrons un peu plus loin que les fichiers logiques ne contiendrons que les chemins d'accès à ces données de fichiers physiques.

42 DB2/400 les données et l'os Structure Un fichier physique de données est constitué : - D'un format qui est la version compilée de la description de fichier. - D'un chemin d'accès qui est la façon d'accéder aux enregistrements du fichier. Le chemin d'accès peut être par ordre d'arrivée c'est à dire sans organisation particulière autre que le n relatif d'enregistrement par rapport à l'ordre dans lequel les enregistrements ont été écrits sur le disque. C'est la forme qui est recommandée. Il peut être par index si une ou plusieurs zones de la description d'enregistrement ont été renseignées comme clé (K). Dans ce cas le chemin d'accès existe physiquement et est organisé sous forme d'arbre binaire afin d'en faciliter le traitement. Cette forme n'est pas recommandée car elle offre peut de sécurité contre une destruction du fichier par maladresse. - Des données regroupées éventuellement par membres distincts. L'accès par défaut étant sur le 1 er membre. Pour accéder à un autre membre, il sera nécessaire de recourir à la commande OVRDBF

43 DB2/400 les données et l'os Mots clé 15.1 Niveau fichier ALTSEQ Définition : ALTSEQ (nom bibliothèque/nom table) nom bibliothèque EST OPTIONNEL Il classe les enregistrements en utilisant une table de remplacement contenant une séquence de classement pour la clé. Autrement dit, le fichier peut être trié sur la clé, si ALTSEQ est mentionné et qu'une séquence de classement est spécifiée pour la clé. Pour cela, il utilise une table. FIFO (premier entré, premier sorti) On utilise ce mot clé pour préciser l'ordre de sortie des enregistrements d'un fichier physique, l'ordre est le premier entré, premier sorti. Ce mot clé n'a pas de paramètre. On ne peut pas l'utiliser avec les mots clé LIFO, UNIQUE et REAFACCPTH. Si ni FIFO, ni LIFO ou ni UNIQUE ne sont spécifiés, les enregistrements seront sortis soit dans l'ordre premier entré, premier sorti ou dernier entré premier sorti. Au moins une clé de champ doit être spécifiée dans le fichier qui contient le mot clé FIFO. FIFO n'est pas valide si l'on précise un type de fichier *CSRC sur une commande de création de fichier logique. LIFO On utilise ce mot clé pour préciser que les enregistrements récupérés dans un membre de fichier physique sont dans l'ordre : DERNIER-ENTRE / PREMIER-SORTI Ce mot clé n'a pas de parametres. On ne peut l'utiliser avec les mots clé suivants : FIFO,UNIQUE et REFACCEPTH. Si,ni LIFO,FIFO et UNIQUE ne sont spécifiés,les enregistrements sont récupérés soit dans l'ordre: PREMIER-ENTRE / PREMIER-SORTI, soit DERNIER-ENTRE / PREMIER- SORTI. Mais l'ordre dans lequel on récupère les enregistrements n'est pas garanti. Au moins un champ clé doit être précisé dans le fichier qui contient le mot clé LIFO. Ce mot clé n'est pas valide lorsque l'on précise un type de fichier (*SRC) sur la commande de création d'un fichier logique.

44 DB2/400 les données et l'os REFSHIFT Mot clé de niveau fichier utilisé pour contrôler l'accès de saisie dans les champs. Ex : REFSHIFT(X) Accepte les lettres de A à Z plus,. - espace transforme tout en majuscules. Il y a 8 valeurs possibles associées à REFFLD qui sont : - X, A, N, S, Y, W, I, D, M et F. Voir aussi Data type/keyboard shift page 4-11 du DDS reference. REF Mot clé de niveau fichier utilisé pour préciser le nom du fichier duquel les descriptions sont tirées. Son format est : REF( Biblio./Fichier de données (nom du format d'enregistremt)) Pour préciser plusieurs fichiers-origine il faut utiliser le mot-clé REFFLD. Pour plus d'infos sur REF et REFFLD, voir : Appendix A, "When to specify REF and REFFLD" DDS reference. ************** Début des données ************************ A REF(ALXREP) A R ARTENR A ARTCOD R A ARTDES R A ARTFRN R REFFLD(FRNDCO) A ARTQST R A ARTQMT R A ARTPRU R A ARTTVA R *************** Fin des données ************************* UNIQUE Ce mot clé n'a pas de paramètres. On utilise ce mot clé pour spécifier que des enregistrements différents avec des valeurs de clé identiques ne sont pas autorisés dans un membre du fichier physique. Aucune addition ou mise à jour dans une clé en double n'est acceptée. Le programme d'application faisant l'écriture ou l'opération de mise à jour reçoit un message d'erreur, de même qu'un programme DFU. Une commande de copie de fichier qui copierait des enregistrements avec des clés en double dans le fichier ne serait pas valide. Quand un fichier logique rattaché à ce fichier physique, a le mot clé UNIQUE, le ou les membres du fichier physique ne peuvent pas avoir de clés en double. Quand on précise le mot clé UNIQUE pour un fichier physique, on doit préciser la valeur de paramètre MAINT (*IMMED) sur la commande de création de fichier (CRTPF) pour créer le fichier. Cela signifie que le chemin d'accès est mis à jour immédiatement au fur et à mesure des changements.

45 DB2/400 les données et l'os Quand le mot clé UNIQUE n'est pas précisé, les enregistrements avec des valeurs de clés en double sont rangés soit dans l'ordre premier entré - premier sorti, soit dernier entré - premier sorti. Si on ne précise pas le mot clé UNIQUE, ni FIFO, ni LIFO, par défaut les enregistrements seront traités en FIFO. Le mot clé UNIQUE ne peut pas être utilisé en même temps que FIFO, LIFO, ou REFACCEPTH. FMT LF A...T.Name Len++TDpB Functions ************** Début des données ************************** A UNIQUE A R ARTENR PFILE(ARTP) A K ARTCOD *************** Fin des données *************************** 15.2 Niveau format d'enregistrement FORMAT Le mot clé FORMAT sert à réutiliser dans un autre fichier ( exemple fichier n 2) des champs identiques, au fichier d'origine ( exemple fichier n 1 ). On utilise ce mot clé de niveau format pour préciser que ce format aura les mêmes spécifications de champs, qu'un niveau format précédemment défini. La syntaxe est la suivante : FORMAT (!LIBRARY-NAME/! PHYSICAL-FILE-NAME) Les points d'exclamations signifient que le nom de la librairie est optionnel. Si l'on ne spécifie pas le nom de la librairie, la liste des librairies (*LIBL) active au moment de la création, est utilisée. Certaines restrictions existent quand à l'utilisation du mot clé FORMAT : - Ne pas spécifier les spécifications des champs, pour ce niveau de format. Spécifier les spécifications des clés, si vous voulez quelles soient actives pour ce fichier ( elles peuvent être les mêmes ou bien différentes, que le niveau de format précédemment défini). - On ne peut spécifier un fichier DDM ( Distributed Data Management ) sur ce mot clé. - Un fichier logique n'est pas autorisé pour le mot clé FORMAT. - Si le fichier physique contenant le format d'enregistrement que vous utilisez est supprimé, le niveau de format reste existant, aussi longtemps que le format d'enregistrement est utilisé dans un fichier quelconque. Par exemple, RECORD dans le fichier 2 utilise le mot clé FORMAT pour partager les spécifications du RECORD dans le fichier 1. Les deux fichiers ont été créés. Si le fichier 1 est

46 DB2/400 les données et l'os supprimé, puis recréé avec différents DDS ( Data Description Specification ), RECORD reste existant dans le fichier 2. Il peut être référencé à partir du niveau de format originel, par d'autres fichiers utilisant le mot clé FORMAT.

47 DB2/400 les données et l'os Niveau zone ALIAS format : alias(nom de remplacement) Ce mot clé alias est utilisé afin de donner un nom de remplacement à la zone correspondante d'une longueur supérieure à 6 ; comprise entre 1 et 30 et commençant obligatoirement par une lettre. Les caractères suivant peuvent être soit des chiffres, soit des lettres soit le trait bas(_)(très utilisé pour les applications développées en COBOL). L'alias est directement transcrit dans le programme lors de la compilation à la place du nom de champ (pos:19/28). Un alias doit obligatoirement être différent d'un autre, ainsi que d'un nom de champ défini dans la DDS, dans le cas contraire un message d'erreur est signalé. L'alias ne peut être utilisé comme un nom de champ(dds), comme clé d'un nom de champ ou comme un nom de champ dans une commande (ex:cpyf). ALWNULL Ce mot clé permet l'autorisation de valeurs nulles pour le champ auquel il faut référence. Lorsque ce mot clé est indiqué, la longueur du champ en vis à vis ne doit pas dépasser caractères. CHECK Ce mot clé attribue un contrôle de validité au niveau du CHAMP dans un fichier écran. Il n'intervient pas directement dans les fichiers physiques. Les codes utilisés pour 'CHECK' sont : - CHECK AB (allow blank) :zone à blanc autorisée, - CHECK ME (mandatory enter):frappe obligatoire, - CHECK MF (mandatory fill) :zone complète si frappée, - CHECK M10 :contrôle modulo 10, - CHECK M11 :contrôle modulo 11, - CHECK VN (valid name) :contenu zone doit être un nom valide, - CHECK VNE(valid name extend). Le contrôle se fait par un chiffre de contrôle permettant de vérifier la validité des données. Ce chiffre est le résultat d'un calcul effectué sur les autres chiffres. Vous ne pouvez pas utiliser CHECK AB, VN, VNE, M10, M11 pour un champ défini en virgule flottante. CMP Ce mot clé est équivalent au mot clé COMP

48 DB2/400 les données et l'os Le format est : CMP(opérateur relationnel, valeur) Le mot clé COMP est préféré - Voir la description du mot clé COMP(comparaison ) pour une explication sur l'utilisation de ce mot clé. COMP Utilisez ce mot-clé de niveau champ pour spécifier la vérification de validité, aux champs que vous définissez lorsqu'il sera référencé ultérieurement lors de la création d'un fichier écran ou à la création d'applications DFU. La syntaxe est: COMP(opérateur relationnel- valeur) Quand l'on définit dans un fichier écran un champ au type zone en entrée (input) référencez le champ que vous êtes en train de définir par la lettre R dans la position 29 ou le mot-clé de REF OU REFFLD. OS/400 copie le mot-clé COMP et les attributs du champ dans le fichier physique vers le champ du fichier écran. Vous pouvez substituer les mot-clé de type contrôle de validité (validity-checking) en les spécifiant pour le champ dans le fichier écran. (voir "référencer, position 29" dans la page 4-9. Il ne faut pas spécifier le mot clé dans un champ de type flottant "F dans la position 35. Les régles pour spécifier ce mot-clé dans un fichier physique sont les mêmes que pour un fichier écran. "voir COMP (comparaison) à la page 4-75 pour pour connaître les informations de Note: COMP est équivalant de CMP COLHDG Le format est : COLHDG('ligne -1'('ligne -2' ('ligne -3'))) Un maximum 3 lignes de 20 caractères chacune est autorisé. FMT PF A...T.Name RLen++TDpB Functions ************** Début des données ********************************* A R REPENR A* A* Client A CLINBR 5 0 TEXT('Code client A COLHDG('N CLI.') A CLIRAI 40 TEXT('Nom du client A COLHDG('NOM DU CLIENT') A CLIRUE 40 TEXT('N et rue A COLHDG('N ET RUE')

49 DB2/400 les données et l'os A CLICMP 40 TEXT('Complément d''adresse') Utilisez ce mot clé de niveau champ afin de spécifier l'entête de colonne utilisée pour ce champ pour la gestion de texte, l'utilitaire QUERY, l'utilitaire de fichiers de données (DFU) et l'utilitaire d'aide de conception d'écran (SDA). Chaque ligne d'entête de colonne doit être entourée d'apostrophes.utilisez l'apostrophe double pour spécifier l'apostrophe à l'intérieur d'une entête de colonne. Si vous ne spécifiez pas COLHDG et que le champ référencé n'est pas récupéré d'un champ référencé, le nom du champ est utilisé. Si vous spécifiez COLHDG et ne spécifiez pas texte, 50 positions d'information d'entête de colonne sont utilisables en tant que texte. Par exemple TEXTE ('ORDER DATE') est construit par OS/400 quand ((when the field spécifies COLHDG ('order''date') but no text keyword) montre comment spécifier le mot clé COLHDG. L'exemple suivant montre comment apparaît le texte du mot clé lorsqu'il est géré par text managment, query, dfu, ou SDA. CUSTOMER ORDER CITY DATE CUSTOMER'S NAME FIELD NNNN XXXXXXXXXXXXXXXXXX XXXXXXXXXXXX CSSID Ce mot clé est utilisé au niveau zone, mais peu aussi être aussi utilisé au niveau record ou fichier. Au niveau zone il est utilisé pour une zone déclarée en type G «graphique» pour préciser que ce champ est de type UCS-2 (unicode). Le format est : CSSID(UCS2-numéro) Numéro est une valeur comprise entre X 7200 et X 72FF et est un numéro valide de CSSID. DATFMT Ce mot clé est utilisé pour indiqué le format de date d'un champ de type date. Le format est : DATFMT(format de date) Les formats de date possibles sont: - *JOB, - *MDY, - *YMD, - *DMY, - *JUL, - *ISO, - *USA, - *EUR, - *JIS. Si ce mot clé n'est pas indiqué le format par défaut est *ISO.

50 DB2/400 les données et l'os DFT Utiliser le mot clé niveau zone DFT pour spécifier une valeur par défaut pour un champ. Le format est : DFT('valeur') ou (X 'valeur') où X = 'valeur hexadécimale' Les valeurs constantes peuvent être : Une valeur caractère dans laquelle chaque caractère est imprimé selon la spécification. Le nombre de caractères est égale à la longueur imprimée du champ. Une valeur hexadécimale, dans laquelle deux caractères identifient un code dans le jeux de caractères. Ces caractères s'impriment dans ce champ. Les indicateurs ne sont pas valides pour ce mot clé. Cependant ils peuvent être utilisés pour conditionner le champ constant avec lequel ce mot clé est spécifié, en précisant l'indicateur sur la même ligne où le champ est spécifié.(voir doc DDS Référence 5-48). Quand l'indicateur concerné est actif (ON), le champ constant correspondant s'imprime avec les quotes. Le mot clé Transparency (TRNSPY) est requis lorsqu'une valeur hexadécimale est spécifiée pour le mot clé DFT. EDTCDE et EDTWRD Ces mots clé sont utilisés pour indiquer comment se fera l'affichage ou l'impression de la zone en vis à vis. Celle-ci est une zone numérique. Ce mot clé n'a pas de répercussion directe pour le fichier physique A R ECR A* A 1 2DATE A EDTCDE(Y) A QMTART 5Y 0B 8 27EDTCDE(Z) A 9 2'Prix unitaire H.T....' A PRUART 7Y 2B 9 27EDTWRD(', ') FLTPCN VIRGULE FLOTTANTE Ce mot clé de niveau champ spécifie la précision de la virgule flottante pour une zone numérique. Le format est: FLTPCN(*single/*double) Le paramètre indique si la zone est en simple ou double précision. Ce mot-clé est seulement valide pour un champ en virgule flottante.

51 DB2/400 les données et l'os Le mot clé est par défaut en simple précision. Dans un champs en simple précision on peut avoir jusqu'à 9 positions maximum et en double précision on peut avoir jusqu'à 17 positions maximum. Si le champs spécifié dépasse la longueur maximale, un message d'erreur s'affichera et le fichier ne sera pas créé. RANGE Le format est: RANGE (Valeur-minimale Valeur-maximale) Utilisez ce mot-clé de niveau champ pour spécifier un contrôle de validité sur la zone que vous définissez lorsqu'elle sera référencée pendant la création d'un fichier écran ou la création d'une application DFU. RANGE ne modifie pas le fichier physique que vous avez défini. Quand vous définissez une zone d'entrée dans un fichier écran, référencez la zone en spécifiant la lettre R en position 29 et le mot-clé REF ou REFFLD. L'OS400 copie le mot-clé RANGE et les autres attributs de zone à partir de la zone du fichier physique dans la zone du fichier écran. Vous pouvez modifier les mots-clé de contrôle de validité en les spécifiant pour la zone dans le fichier écran. Les données entrées doivent être supérieures ou égales à la valeur minimale et inférieures ou égales à la valeur maximale. Quand la zone est de type caractère, les valeurs du paramètre doivent être entre apostrophes. Quand la zone est numérique, les apostrophes ne doivent pas être spécifiées. Les indicateurs d'option ne sont pas valides pour ce mot-clé. La donnée entrée dans une zone numérique est alignée sur le nombre de décimales spécifiées en colonnes 36 à 37, les blancs de début et/ou de fin sont remplis avec des zéros. Ne pas spécifier le mot-clé RANGE pour une zone en virgule flottante (F en position 35). Les règles pour spécifier ce mot-clé dans un fichier physique sont les mêmes que pour un fichier écran. Voir RANGE à la page pour plus d'informations, ainsi que pour un exemple montrant comment spécifier ce mot-clé. REFFLD Le format est : REFFLD ((nom du format d'enregistrement/)nom du champ référencé ((*SRC ou biblio/fichier de données))) Mot clé de niveau fichier utilsé pour réferencer un champ sous 3 conditions : - quand le nom du champ réferencé est different du nom se trouvant dans les positions entre 19 et 28,

52 DB2/400 les données et l'os quand le nom du champ réferencé est le meme que celui se trouvant dans les positions entre 19 et 28 mais que le format d'enregistrement, le fichier ou la bibliothèque du champ référencé est different de celui précisé avec REF, - quand le champ réferencé se trouve dans le même fichier source DDS que le champ de référence. TEXT Le format est : TEXT('description') On utilise ce mot clé au niveau enregistrement ou au niveau champ pour effectuer une description de texte. La description doit être entre apostrophes, avec un maximum de 50 caractères. Au cas ou plus de 50 caractères sont spécifiés, le mot clé est accepté. Toutefois, les caractères supplémentaires ne sont pas pris en compte. Si TEXT n'est pas spécifié et que le mot clé COLHDG est précisé, 50 positions sont utilisées par défaut. Si l'on ne précise pas COLDHG et que le champ n'est pas concaténé, le texte est pris dans le champ physique TEXT s'il existe. Si l'on ne précise pas COLDHG et que le champ est concaténé, Il n'y a pas de texte. NB : L'on peut préciser TEXT aussi bien au niveau enregistrement qu'au niveau champ. On peut préciser a la fois TEXT et FORMAT au niveau enregistrement car l'enregistrement contient toujours du texte. VALUES Le format est: VALUES(VALUE1{VALUE-2----{VALUE-100}}) Sa destination est de valider la vérification du champ que vous avez défini quand il est référencé plus tard lors de la création du fichier écran ou après la création d'une application dans DFU. VALUES n'affecte pas le fichier physique que vous avez défini. Mais quand vous définissez un champ de saisie dans un fichier écran vous pouvez référencer le champ que vous avez défini (en spécifiant R en position 29 et REF ou REFFLD mot clé). Pendant la création du fichier écran l'os400 copie les valeurs du mot clé et les attributs du champ du fichier physique dans le champ qui est dans le fichier écran. Vous pouvez substituer, vérifier, valider ce mot clé en le spécifiant pour le champ dans le fichier écran. Voir "REF (réference) page pour plus de détails". Vous ne pouvez pas spécifier le mot clé values dans un champ décimal là ou il y a une virgule flottante (il faut mettre F dans la colonne 35) les règles de spécification du mot clé VALUES dans un fichier physique sont les mêmes que pour le fichier écran.

53 DB2/400 les données et l'os Niveau clé Les mots clés possibles sont identiques entre fichiers physiques et logiques. 16 fichiers logiques Un fichier logique est un objet OS400 qui contient des chemin d'accès par clé d'index aux données d'un ou plusieurs fichiers physiques. Pour sécuriser les données tout chemin d'accès au données doit être réalisé sous la forme d'un fichier logique. En effet tant qu'il existe au moins une relation entre un fichier logique et sa base physique, la base physique que constitue le fichier physique est indestructible par une commande système. A l'inverse lorsque l'on désire supprimer un fichier physique, il faut s'assurer par la commande DSPDBR (Display Data Base Relations). Qu'aucun fichier logique n'est plus basé sur le physique à détruire Structure Un fichier logique comprend, comme un fichier physique, une description de format et un chemin d'accès mais il ne contient pas de membre de données. Ces dernières sont uniquement dans le fichier physique. Le format d'enregistrement d'un fichier logique sert essentiellement à décrire les clés d'index servant à accéder aux données. Mais il peut servir également à décrire un format d'enregistrement différent du fichier physique ne laissant apparaître que certaines zones du physique. Il s'agit alors d'une vue logique à ne pas confondre avec une vue SQL Logiques joints Il est possible de créer un fichier logique qui soit basé sur plusieurs physiques et de créer un format d'enregistrement purement logique qui donne accès à diverses zones de plusieurs physiques étant vues alors par les programmes d'application comme un seul fichier. Un tel fichier est appelé un fichier joint. Pour créer un logique joint il faut prendre un fichier dit "de base" qui servira de référence pour effectuer les lectures principales. Il doit exister ensuite dans chaque paire de fichiers une zone dont une valeur soient commune aux deux fichiers. En général ce sera une zone ayant la même signification. Les lectures de fichier en fichier se feront automatiquement. Un fichier logique joint ne peut être utilisé qu'en lecture uniquement. Une tentative de mise à jour pourrait provoquer des résultats inattendus. Les zones de joint des fichiers logiques joints devront être codifiées avec un soin tout particulier. Il sera préférable que les noms de zones soient tous différents pour éviter les

54 DB2/400 les données et l'os quiproquo au programmeur et au système. L'usage du mot clé de niveau zone REFFLD est particulièrement recommandé pour définir les zones de jointures.

55 DB2/400 les données et l'os Conversions de type de données Il est possible de convertir le sous type d'une donnée numérique entre le fichier physique et le fichier logique. Pour plus d'informations sur ce sujet consultez la brochure IBM AS400 DDS reference SC chapitre Mots clé Comme pour les fichiers physique il existe des mots clé pour chaque niveau du fichier Niveau fichier DYNSLT Ce mot clé vous permet d'indiquer que la sélection/omission d'enregistrements s'effectuera conformément aux instructions de niveau sélection/omission dynamiquement pendant le traitement du fichier. Ce qui veut dire que à chaque lecture du fichier le système testera si il doit fournir au programme l'enregistrement lu ou si il doit passer automatiquement au suivant. Cette façon de procéder peut ralentir quelque peu le système, mais est parfois beaucoup plus rentable que la mise à jour de chemins d'accès particuliers. Ce genre de fichier logique, dans le cas ou le nombre d'enregistrements sélectionnés représente un pourcentage important par rapport à l'ensemble du fichier peut être beaucoup plus rapide et rentable en charge CPU qu'un OPNQRYF. Il n'est pas possible d'utiliser DYNSLT avec REFACCPTH. FCFO Ce mot clé permet d'indiquer pour les clés dupliquées que la première fournie sera la clé modifiée en premier. JDFTVAL Ce mot clé doit être utilisé pour indiquer au système qu'il doit prendre des valeurs par défaut pour les joints secondaires où il ne trouverait pas de correspondance de valeur. Si ce mot clé n'est pas indiqué, le système ne délivrera pas un enregistrement si tous les joints indiqués ne sont pas satisfaits. Les valeurs par défaut peuvent être modifiées par l'emploi du mot clé DFT.

56 DB2/400 les données et l'os Niveau enregistrement PFILE Ce mot clé sert à indiquer sur quel fichier physique est basé le fichier logique. Ce mot clé peut contenir plusieurs valeurs. Dans ce cas il s'exclue avec le mot clé JFILE. Le maximum de fichiers physiques indiqués est de 32. L'usage de ce mot clé avec plusieurs valeurs est réservé aux fichiers logiques basés sur plusieurs fichiers physiques de structure identique. Si d'aventure une zone ne figurait pas dans tous les formats d'enregistrement de tous les fichiers physiques décrits, elle ne pourrait pas être indiquée dans le format du fichier logique. JFILE L'usage de ce mot clé est identique à PFILE mais sans les restrictions de zones et est donc spécialement conçu pour les fichiers joints. L'indication de fichier DDM (data distributed management) n'est autorisée que pour des fichiers logiques créés sur un système distant Niveau joint Ce niveau n'existe que pour les fichiers joints R LENENR JFILE(ENCP LICP) J JOIN(ENCP LICP) JFLD(ENCRCD LICRCD) ENCRCD JREF(ENCP) ENCDCT ENCEDI LICQTE LICQET LICQDU K ENCRCD JDUPSEQ Ce mot clé indique dans quel ordre les enregistrements des joints doubles sont présentés en lecture. Le format est : JDUPSEQ(nom de champ!*descend!) Le nom du champ indiqué ne peut être un champ de joint. JFLD Ce mot clé indique les noms des deux champs dans le fichier origine et le fichier destination qui doivent contenir une valeur identique afin de créer le joint. Si le mot clé JOIN n'est pas spécifié, la colonne 17 doit contenir un "J". Le format est :

57 DB2/400 les données et l'os JFLD(nom du champ départ nom du champ destination) Il est impératif d'indiquer au moins un JFLD par JOIN déclaré. JOIN Ce mot clé permet d'indiquer les fichiers joints deux à deux. La colonne 17 de la spécification doit contenir un "J". Le format est : JOIN(fichier origine fichier destination) Chaque fichier indiqué doit avoir été déclaré dans le mot clé JFILE Niveau champ CONCAT Ce mot clé permet de concaténer un ou plusieurs champs d'un fichier physique pour n'en former qu'un seul dans un fichier logique. La zone résultante doit être indiquée dans les colonnes 19 à 28 de la spécification A. Le format est : CONCAT(champ 1 champ 2...n) Un champ indiqué comme paramètre du mot clé CONCAT et la zone résultante de ce même mot clé ne peuvent être indiquées simultanément comme zone clé d'un fichier logique. JREF Ce mot clé est a utiliser pour les bases de données plus ou moins bien définies. Il sert à indiquer pour les zones de jointure dans quel fichier physique sera prise la valeur de la zone au cas où le nom de zone est identique dans plusieurs fichiers physiques et que l'usage du mot clé REFFLD a été omis pour définir la zone dans les fichiers secondaires. Le format est : JREF(nom fichier ou no relatif de fichier) Le no relatif correspond à l'ordre décrit au mot clé JFILE. Si un fichier physique est décrit deux fois avec le mot clé JFILE vous devez impérativement utiliser le no relatif de fichier. Si aucun nom de zone n'est indiqué plusieurs fois dans différents fichiers, ce mot clé n'est pas à utiliser. RENAME Ce mot clé est a utiliser lorsque vous désirez modifier la description d'un champ dans un fichier logique par rapport à sa description dans un fichier physique. Le format est : RENAME(nom fichier physique nom de champ)

58 DB2/400 les données et l'os Ce mot clé peut être utilisé plusieurs fois dans le même format d'enregistrement avec le même nom de champ comme paramètre. Cela permet soit d'utiliser le fichier avec des programmes indiquant des noms de zones différents (comme en COBOL où des noms de zones peuvent avoir 30 cs de long), soit de mapper un champ d'un fichier physique dans deux ou plusieurs champs du logique, ou encore d'utiliser plusieurs noms différents pour une même zone mémoire. SST Ce mot clé permet de définir une sous chaîne d'un champ alpha ou hexadécimal. Le format est : SST(nom de champ position départ longueur) Nom de champ identifie un champ qui doit être déjà indiqué comme zone du fichier logique dans une spécification précédente ou il doit exister dans le fichier physique indiqué au mot clé PFILE ou JFILE. Le champ résultant indiqué dans les colonnes 19 à 28 est du même type que le champ paramètre du mot clé. Si le type de données n'est pas indiqué il sera par défaut de type H (hexadécimal) ou A (alpha). L'usage de la zone résultante doit être I (input) ou N (neither). La longueur du champ résultant est optionnelle si longueur est indiqué comme paramètre. Mais l'un ou l'autre doivent être indiqués ou les deux et égaux. Vous ne pouvez pas indiquer simultanément les mots clé CONCAT, RENAME ou TRNTBL avec le mot clé SST. Le champ indiqué comme paramètre ne peut être défini antérieurement avec les mots clé CONCAT, SST ou TRNTBL. TRNTBL Ce mot clé sert à indiquer qu'il faut utiliser une table de traduction entre le fichier physique et le fichier logique pour présenter les valeurs de ce champ. Le format est : TRNTBL(nom librairie/nom de table de traduction) L'usage de ce mot clé n'est valide que pour les zones alpha en entrée seulement (I) ou N (neither). La traduction est faite au moment de la lecture dans le fichier physique. Si d'autres opérations de classement ou de sélection sont indiquées pour ce champ elles sont faites après traduction Niveau clé

59 DB2/400 les données et l'os ABSVAL format : pas de paramètres ABSVAL est utilisé afin de ne pas tenir compte du signe auquel le champ est assigné. Les enregistrements sont classés selon leur séquence en tenant compte de leur valeur absolue. ABSVAL ne peut etre associé à un champ de type alpha et ne peut être utilisé avec les motsclé suivant : DIGIT,SIGNED,UNSIGNED et ZONE. Nota : si absval est associé avec le mot clé ALTSEQ ce dernier est ignoré. DESCEND C'est un mot clé de NIVEAU CLE qui permet d'accéder aux valeurs du champ clé en ORDRE DECROISSANT. La valeur par défaut est par ordre croissant. Le type de la valeur du champ clé peut être soit numérique soit caractère. DIGIT Ce mot clé est l'équivalent inverse du mot clé zone (Voir ce mot clé). Il ne s'occupe que de la partie droite de chaque octet de la zone clé. NOALTSEQ Utilisé lors de la creation de fichier physique C'est un mot clé de niveau zone-clé :(K). Annule l'effet de Altseq (mot clé de niveau fichier) pour la zone cle en regard de laquelle il est codifie. Ainsi la table de remplacement de fichier spécifié par altseq ne s'applique pas à la zone clé. Utilisation : Par exemple, pour les tris lorsque que l'on ne veut pas prendre en compte les majuscules et minuscules SIGNED Ce mot clé est identique pour les fichiers logiques et les fichiers physiques. On ne peut pas l'utiliser avec les mots-clés ABSVAL,UNSIGNED,ZONE ou DIGIT. SIGNED (mot clé de niveau champ) est incompatibe avec ALTSEQ (mot clé de niveau fichier). Si vous spécifier SIGNED pour un champ clé, NOALTSEQ est actif pour ce champ clé meme si ALTSEQ est précisé au niveau du fichier. Ceci se passe que NOALTSEQ soit précisé ou pas. Ce mot clé de niveau clé est utilisé pour préciser que l'os400 doit tenir compte des signes des valeurs quand il classe les clés. Ce mot-clé n'est pas valide pour un champ alpha-numérique

60 DB2/400 les données et l'os (ce mot-clé n'a pas de paramétres). Par défaut, sans mot clé de rangement précis et sans le mot-clé ALTSEQ le champ est considéré signé. UNSIGNED C'est le fait d'ignorer le signe d'un champ numérique. Utilisez ce mot clé de niveau clé pour spécifier que les champs numériques soient ordonnées comme une chaîne de donnée binaire non signée. Les champs alphanumériques sont par défaut sensés contenir des valeurs non signées. UNSIGNED est valide dans les champs clé du fichier physique sans tenir compte de quelle type de donnée il s'agit. Vous ne pouvez pas spécifier le mot clé UNSIGNED avec les mots clé SIGNED ou ABSVAL. Le mot clé UNSIGNED est pris par défaut dans les situations suivantes : - Quand ALTSEQ est spécifié au niveau fichier pour un champ clé zoné, - Quand ZONE ou DIGIT est spécifié pour un champ clé zoné, - Pour tous les champs alphanumériques. Remarque : Spécifier UNSIGNED pour les champs de type virgule flottante peut donner des résultats non attendus. ZONE Ce mot clé n'a pas de paramètre. Le mot clé,lorsqu'il est utilisé spécifie qu'au niveau des champs,seul les 4 premiers bits à gauche sont pris en compte pour servir de clé (seuls les quatre premiers bits les plus à gauche sont donc pris en compte), le reste du champ est remplacé par des zéros. Ce mot clé porte néanmoins sur la totalité du champ-clé et non sur la partie prise en compte exclusivement. ZONE est incompatible avec ABSVAL ou avec SIGNED ou DIGIT. Si vous associez le mot ZONE à un champ-clé,la valeur de ce champ est traitée comme une chaîne de caractères binaire non signée. exemple: valeur hexadécimal comme-clé A C1 C B C2 C ==> partie prise C C5 C en compte comme clé REPRESENTATION 0040 K CODE ZONE

61 DB2/400 les données et l'os Niveau sélection/omission Ce niveau est identifié par le caractère "S" ou "O" indiqué en colonne 17 d'une spécification A de description de fichier logique. ALL Ce mot clé indique quelle attitude prendre pour les enregistrements qui ne répondent pas aux critères de sélection ou omission décrits précédemment. L'action menée est dépendante de la valeur "S" (sélection) ou "O" (omission) indiquée en colonne 17 de la ligne où figure le mot clé. L'usage de ce mot clé bien que facultatif est vivement recommandé pour éviter tout résultat inattendu. La valeur utilisée par défaut étant opposée à la valeur indiquée en colonne 17 de la dernière ligne de sélection/omission. COMP Voir la définition de ce mot clé au chapitre fichiers physiques. RANGE Voir la définition de ce mot clé au chapitre fichiers physiques. VALUES Voir la définition de ce mot clé au chapitre fichiers physiques. ************** Début des données *********************************** A DYNSLT A R COMENR JFILE(ENCP DECP CLIP ARTP) A J JOIN(ENCP DECP) A JFLD(ENCNCM DECENC) A JDUPSEQ(DECART) A J JOIN(ENCP CLIP) A JFLD(ENCCLI CLINUM) A J JOIN(DECP ARTP) A JFLD(DECART ARTCOD) A ENCNCM A ENCCLI A ENCDCM A ENCFCM A ENCVCM A ENCMCM A DECENC A DECART A DECQCT A DECQLT A DECUPR A CLINUM A CLIRAI A ARTCOD A ARTDES A K ENCCLI A K ENCDCM A S ENCFCM COMP(NE 'O')

62 DB2/400 les données et l'os A O ENCVCM COMP(EQ 'N') *************** Fin des données ******************************* 18 Autres fonctions base de données 18.1 National Language Support En V3R1 le premier pas vers la mise en oeuvre de Unicode a été effectué en encodant les noms d'objets dans certains composants de IFS. Avec la V3R6 ce support a été étendu pour permettre aux fichiers BD de stocker des données dans Unicode (USC2 niveau 1). Par exemple des données en français, en allemand, en hébreu, en chinois, en russe ou en toute autre langue peuvent coexister dans un même fichier BD. SQL a la possibilité de convertir de et vers Unicodeafin que les requêtes et les manipulations sur les données Unicode puissent être réalisées dans une même application Predictive Query Governor La plupart des bases de données comportent un genre de Query Predictor, qui permet de s'assurer que les requêtes ne s'exécutent pas pendant un temps anormalement long. Au bout d'un certain temps, cet outil stoppe la requête en cours si elle dépasse le temps prévu. Dans DB2/400 si la prévision dépasse une certaine limite la requête nest même pas lancée. Ainsi les ressources du système ne sont pas gaspillées à exécuter une requête qui serait arrêtée de toutes façons. Un optimiseur de requêtes est utilisé pour analyser comment il faut attaquer la base avant l'exécution d'une requête et quel est le meilleur moyen d'y parvenir dans le temps imparti. La prédiction de la durée d'exécution fait partie de l'analyse réalisée par l'optimiseur. Ce temps prévu est mis en regard de la limite associée à cet utilisateur. Si la durée calculée est supérieure à la limite autorisée, un message est envoyé à l'utilisateur qui peut choisir soit de stopper, soit d"exécuter malgré le dépassement de limite Amélioration des performances On peut utiliser la commande EXPLAIN pour prévoir ou visualiser les caractéristiques d'exécution d'une requête. Ceci est aussi réalisé dans l'historique du travail si le programme qui lance la requête est en mode DEBUG actif. On peut alors utiliser les informations recueillies pour améliorer les performances soit en modifiant la base de données, soit en modifiant la requête. Pour les accès séquentiels l'utilisateur peut mettre en oeuvre des mécanismes de cache très pointus comme le cache statique ou l'expert cache. Un cache expert s'agrandit ou s'amenuise en fonction des besoins. Ce type de cache utilise des algorithmes d'intelligence artificielle (IA) pour modifier dynamiquement la taille du cache, en fonction de la charge CPU, des prévisions d'activité de la base de données et des ressources allouées. De même un utilisateur peut définir un cache statique en mémoire pour permettre à une table complète ou à une portion de table d'entrer dans une zone de mémoire Bases de données distribuées

63 DB2/400 les données et l'os L'AS400 permet à un programme applicatif d'accéder de façon transparente à une base de données situées sur un autre système de la même manière que si elle était en local. Autrement dit un programme peut traiter un fichier sans savoir réellement où il se trouve physiquement. La possibilité d'accéder à une base de données distante et pour d'autres systèmes d'avoir accès à la base de données locale est réalisée grâce à la mise en oeuvre de deux architectures : - DRDA (Distributed Relational Database Architecture) pour SQL, - DDM (Distributed Data Management) pour les accès en natif Passerelles vers d'autres SGBDR L'AS400 fonctionne avec les bases de données supportant DDM ou DRDA, mais il offre également une approche intégrée pour accéder aux autres bases de données. Ce support permet de travailler directement avec n'importe quel SGBD d'un autre constructeur présent sur le réseau. En plus de la Distributed Database Directory de l'os400, il ya un Distributed Driver Manager. Ce gestionnaire fonctionne avec les drivers des différentes bases de données Unix et Micro et permettent à une application AS400 de travailler avec ces bases de données de la même manière qu'avec une base de données DRDA. En sortie, le support d'un driver ODBC est également disponible pour les bases compatibles avec l'architecture distribuée de Microsoft Data Propagator Dans un environnement distribué il peut exister plusieurs exemplaires d'un même fichier sur des systèmes distincts. La modification de l'un des exemplairesn'est pas immédiatement répercutée sur les autres exemplaires. Data Propagator fourni un mécanisme de répercussion des mises à jour sur tous les systèmes. A intervalles définis par l'utilisateur, les modifications d'un fichier donné sont répliquées à travers l'ensemble des systèmes même si tous ne sont pas connectés au réseau simultanément. Les modifications peuvent être répercutées sur toute base DB2 aussi bien sous OS/2 que sous AIX ou MVS Opticonnect Comme système isolé, l'as400 admet des configurations assez importantes. Mais pour des clients ayant des besoins allant au delà de ce qu'il est possible de faire avec un seul AS400 et même avec un réseau de systèmes, les charges liées au trafic réseau vont limiter les performances. Opticonnect pour l'os400 permet à plusieurs AS400 d'être reliés entre eux par fibre optique. Dans une telle configuration, certaines machines seront réservées aux traitements applicatifs et d'autres machines seront spécialisées pour les traitements base de données. Opticonnect met en oeuvre DDM, mais avec un protocole particulier qui élimine les couches redondantes de contrôle de transmission liées aux lignes LAN bruyantes. Avec Opticonnect il faut seulement ajouter 3 millisecondes au temps nécessaire pour accéder à la base de données qui oscile de 3 à 8 millisecondes en temps normal et selon les modèles de DASD (Data Auxillary Storage Drive).

64 DB2/400 les données et l'os Bases de données parallèles Dans un système tel que l'as400, avec de multiples processeurs, les opérations base de données peuvent être partagées entre plusieurs processeurs pour atteindre un haut niveau de performances. Par exemple, un requête peut être divisée en sous requêtes, chacune s'exécutant sur des processeurs distincts et sur des machines distinctes. Deux approches permettent de réaliser de telles améliorations La base de données SMP (Symetric Multiprocessing Parallel) Disponible sur les AS400 multiprocesseurs. Les requêtes sont fractionnées en unités de travail plus petites, réparties ensuite entre les processeurs, en une répartition équitable de la charge sur les différents processeurs. La commande CHGQRYA (Change Query Attributs) comporte une option permettant à l'utilisateur que la requête doit mettre à proffit les processeurs multiples La base de données faiblement associée Ce support de base de données répartie permet à de multiples AS400 de s'interconnecter pour fonctionner comme une seule base de données. On appelle ce type d'interconnection une grappe faiblement associée, parce que chaque système (un noeud ou node) de la grappe tourne avec son propre système d'exploitation et ne peut adresser que sa propre mémoire. Dans l'absolu, il n'y a pas de limite au nombre de connections, mais pour l'instant seulement 32 systèmes peuvent être interconnectés. Cela correspond à une base de données de 16 To avec 128 processeurs tournant en parallèle, ce qui n'est pas si mal pour un début. Pour la mise en oeuvre, voir les commandes : - CRTNODGRP create node group, - CHGNODGRPA change node group attributs, - CRTPF mots clé NODGRP et PTNKEY (partitionning key), - CREATE TABLE pour accès SQL.

65 DB2/400 les données et l'os Sécurité des données 20.1 La journalisation Un journal est l'enregistrement chronologique des modifications apportées à un ensemble de données. Le but du journal est d'offrir la possibilité de reconstruire une version précédente de cet ensemble de données. Deux objets AS400 servent de support à la journalisation. L'un est le journal, l'autre le récepteur de journal. Le journal identifie les objets à journaliser, le récepteur de journal contient les entrées de journal (les modifications effectuées). Chaque entrée de journal contient plusieurs éléments d'information, dont le nom du fichier, de la bibliothèque, le nom du programme, le numéro relatif d'enregistrement, l'heure et la date, l'identification du travail, de l'utilisateur et du poste de travail. La copie de l'enregistrement modifié est également inscrite, et optionnellement, la copie avant modification peut aussi être inscrite. Les journaux de base de données sont utilisés pour pouvoir reprendre après une panne système, mais aussi après des problèmes de base de données liés à des programmes. S'il se produit une anomalie, les fichiers journalisés sont automatiquement restaurés lors de l'ipl suivant. Il est possible de restaurer soit en avant soit en arrière. La restauration supprime les modifications erronées du fichier La protection des chemins d'accès par le système (SMAPP) IBM a conçu SMAPP (System Managed Access Path Protection) pour réaliser une journalisation automatique des chemins d'accès fichiers, ntamment pour les utilisateurs qui n'utilisent pas la journalisation explicite. Le système calcule automatiquement la durée maximale qu'il va allouer à la reconstruction des chemins d'accès pendant l'ipl après un arrêt anormal. Il utilise ensuite cette durée maximale pour déterminer combien il faut journaliser de chemins d'accès. L'utilisateur a la possibilité de modifier cette valeurcalculée dans un sens ou dans l'autre. Plus la valeur est petite, plus il faudra de ressources à la journalisation, plus la valeur est grande, plus l'ipl durera dans le temps Le contrôle de validation Lorsque de multiples mises à jour de plusieurs tables sur une seule opération sont nécessaires, il est possible que de par l'action de l'utilisateur final ou de par une anomalie de fonctionnement, une partie seulement des mises à jour soient effectuées. Si la situation en reste là, l'intégrité de la base de données est compromise. Le système doit donc gérer la possibilité de prendre en compte ou d'annuler un groupe de mises à jour. Celà s'appelle le contrôle de validation. Le système doit donc protéger un groupe de mises à jour et ne les libérer que lorsque toutes les mises à jour sont effectuées. Une opération COMMIT permet au système d'enterriner un groupe de modifications, alors que l'opération ROLLBACK permet d'invalider un groupe de mises à jour. Le contrôle de validation utilise la journalisation pour mettre en oeuvre ces opérations.

66 DB2/400 les données et l'os DASD de technologie RAID 5 Les disques sont mécaniques et tout ce qui est mécanique est suceptible de tomber en panne. Il existe deux techniques on line pour protéger les données. La technique des disques miroir (mirroring) et la technique de duplication partielle sur grappes de disques. La technique des disques miroir oblige à une configuration dupliquée avec copie systématique de toutes les opérations sur deux unités de disques différentes. Le système continue à fonctionner si une unité de disque tombe en panne, mais est indisponible dans le cas statistiquement hautement improbable où les deux unités tombent en panne simultanément. Les disques miroir offrent le maximum de disponibilité mais sont une solution coûteuse surtout si on duplique aussi les IOP et les BUS, ce qui offre le maximum de sécurité. Une autre approche consiste à utiliser des disques en grappe. Les informations sont réparties sur tous les disques et ont utilise un disque redondant. De cette manière, si un des disques tombe en panne, il est possible de reconstituer l'ensemble de l'information. Cette technologie est appelée RAID (Redondant Array of Inexpensive Disk). La technique consiste à effectuer une opération XOR sur les données de tous les secteurs du groupe. l'opération XOR entre deux opérandes permet de retrouver un des opérandes par un nouveau XOR entre l'autre opérande et le résultat. Les résultats sont stockés sur le disque redondant. Ainsi toute donnée perdue par une panne d'un des disques peut être reconstituée par un disque plus le résultat du dsique redondant. Si c'est le disque redondant qui est en panne, tioutes les infos initiales sont disponibles.

67 DB2/400 les données et l'os Limitations Les limitations actuelles sont le fait de la version actuelle du SLIC, dans l'absolu le MI n'a pas de limite à la taille des objets système car il est indépendant de la technologie. Par le passé, les limitations ont déjà été repoussées plusieurs fois. Element Taille maxi PF 240 Go nombre d'enregistrements par PF > LF 4 Go clé composée ou simple 2048 octets PF par LF joint 32 champ de type CHAR octets champs par record Nom d'un fichier DB 18 caractères