BD 400

Prface
La base de donnes de lAS/400, voil un sujet qui a fait couler beaucoup dencre ! Est-elle relationnelle ? Faut-il lacheter part ? Le nom de DB2/400 lui permet dtre enfin nomme et donc compare. Il nest pas possible de commander DB2/400 car cette fonction est intgre lOS/400, livre en standard, comprise dans le prix. Cest la seule chose qui nait pas chang depuis le dbut du systme 38. La liste des amliorations est longue puisquelle est maintenant conforme aux diffrents standards des bases de donnes relationnelles (ANSI X3.135.1992, ISO 9075.1992, FIFS 127-2SQL). Ecrit par un professionnel de lAS/400, aux qualits pdagogiques reconnues, ce livre est un bon complment une formation IBM. Il apportera au lecteur une vision globale des fonctionnalits de DB2/400. Danile LHERMITE Responsable de la Filire Formation AS/400 IBM France
Table des matires
AVANT-PROPOS ................................................................................................................1 Nologismes et typographie ...................................................................................................2 1 - INTRODUCTION...........................................................................................................3 DB2/400 : la base de donnes de lOS/400 ............................................................................3 Les caractristiques de DB2/400............................................................................................4 SGBD Relationnel .............................................................................................................. 4 Les interfaces ..................................................................................................................... 5 La scurit.......................................................................................................................... 5 La base de donnes distribue ........................................................................................... 6 Conclusions ............................................................................................................................6 2 - PRINCIPES GNRAUX .............................................................................................7 Introduction ............................................................................................................................7 Organisation de l'information ............................................................................................ 7 Cration d'objets ................................................................................................................ 8 Les fichiers ...........................................................................................................................10 Gnralits ....................................................................................................................... 10 Description externe .......................................................................................................... 11 L'identificateur de format................................................................................................. 12 Les enregistrements ..............................................................................................................13 Ajout ................................................................................................................................. 13 Suppression ...................................................................................................................... 13
II
DB2/400 ET LA GESTION DES DONNES SUR AS/400
Liens avec la programmation ...............................................................................................15 Exemples en langage de contrle..................................................................................... 16 Exemples en RPG............................................................................................................. 19 Les DDS ...............................................................................................................................22 Introduction...................................................................................................................... 22 La spcification A ............................................................................................................. 23 La hirarchie.................................................................................................................... 24 Exemples .......................................................................................................................... 25 Les types de donnes ........................................................................................................ 25 Conclusions ..........................................................................................................................27 3 - LES FICHIERS PHYSIQUES .....................................................................................29 Les tapes de la cration d'un fichier physique par DDS......................................................30 La codification des fichiers physiques..................................................................................30 Principes .......................................................................................................................... 31 Le dictionnaire ................................................................................................................. 31 Les cls ............................................................................................................................. 33 Liens avec les fichiers d'affichage.................................................................................... 36 Partage de format ............................................................................................................ 39 Valeur par dfaut ............................................................................................................. 40 En-tte de colonne............................................................................................................ 40 Le traitement des dates..................................................................................................... 42 Les zones de longueur variable........................................................................................ 44 Environnement multinational........................................................................................... 46 Les principaux mots-cls des DDS ................................................................................... 47 La commande de cration de fichiers physiques .................................................................49 Dfinition du fichier ......................................................................................................... 49 Cration d'un fichier sans DDS........................................................................................ 50 Gravit des messages ....................................................................................................... 50 Les membres..................................................................................................................... 51 Le chemin d'accs ............................................................................................................ 51 Ecriture force en mmoire secondaire ........................................................................... 54 Les fichiers physiques et la mmoire secondaire ............................................................. 54 Les verrouillages .............................................................................................................. 58 Le partage du bloc de contrle (ODP)............................................................................. 58 Les groupes dactivation et lODP................................................................................... 63 Les enregistrements dtruits............................................................................................. 63 Lidentificateur de format ................................................................................................ 64 Les oprations permises ................................................................................................... 65 Le tri................................................................................................................................. 66 Conclusions ...................................................................................................................... 67 Les principaux paramtres de la commande CRTPF....................................................... 67 Les membres ........................................................................................................................68 Gnralits ....................................................................................................................... 69 Mise en uvre .................................................................................................................. 71
Table des matires
III
Exemple............................................................................................................................ 73 Conclusions ...................................................................................................................... 75
IV
La gestion des fichiers physiques .........................................................................................75 Dfinition ......................................................................................................................... 76 Destruction....................................................................................................................... 76 Visualisation..................................................................................................................... 76 Modification de la structure............................................................................................. 76 Les membres..................................................................................................................... 80 Sauvegarde....................................................................................................................... 80 Rorganisation ................................................................................................................. 80 Les utilitaires.................................................................................................................... 81 Conclusions ..........................................................................................................................81 Les principales commandes..................................................................................................81 Les principaux menus...........................................................................................................82 4 - LES FICHIERS LOGIQUES .......................................................................................83 Principes...............................................................................................................................83 Prsentation ..................................................................................................................... 83 Structure........................................................................................................................... 83 Utilisation......................................................................................................................... 85 Les diffrents types de fichiers logiques........................................................................... 90 Les tapes de la cration d'un fichier logique.................................................................. 91 Les fichiers logiques non-joints............................................................................................91 Principes .......................................................................................................................... 91 La rfrence aux fichiers physiques ................................................................................. 91 Slection et omission ........................................................................................................ 93 Les chemins daccs ......................................................................................................... 96 Les redfinitions de zones ................................................................................................ 98 Les fichiers logiques multiformats.................................................................................. 100 Conclusions sur les fichiers logiques non joints ............................................................ 105 Les fichiers logiques joints.................................................................................................106 Principes ........................................................................................................................ 106 La codification ............................................................................................................... 106 Remarques...................................................................................................................... 110 Conclusions sur les fichiers logiques joints ................................................................... 112 Les principaux mots-cls des DDS des fichiers logiques ..................................................112 Les DDS de niveau Fichier ............................................................................................ 112 Les DDS de niveau Format ............................................................................................ 113 Les DDS de niveau Zone ................................................................................................ 113 Les DDS de niveau Cl................................................................................................... 114 Les DDS de niveau Slection ......................................................................................... 114 La commande de cration des fichiers logiques .................................................................115 Les membres................................................................................................................... 115 Le programme slecteur de format ................................................................................ 115 Estimation de la taille d'un fichier logique .................................................................... 115 Les principaux paramtres de la commande CRTLF..................................................... 116 Les membres ......................................................................................................................117
Table des matires
Les chemins daccs ...........................................................................................................119 Performances ................................................................................................................. 119 Les limites....................................................................................................................... 119 La reconstruction ........................................................................................................... 120 La sauvegarde ................................................................................................................ 121 La gestion des fichiers logiques..........................................................................................121 La dfinition ................................................................................................................... 121 La destruction................................................................................................................. 121 La visualisation .............................................................................................................. 121 Les membres................................................................................................................... 122 La sauvegarde ................................................................................................................ 122 Les utilitaires.................................................................................................................. 122 Conclusions sur les fichiers logiques..................................................................................122 Les principales commandes................................................................................................123 Les principaux menus.........................................................................................................123 5 - SCURIT ET INTGRIT DES DONNES ........................................................125 Introduction ........................................................................................................................125 La journalisation.................................................................................................................127 Les principes .................................................................................................................. 127 La journalisation des fichiers physiques ........................................................................ 138 La journalisation des chemins daccs .......................................................................... 141 Conclusions sur la journalisation .................................................................................. 145 Le contrle de validation....................................................................................................145 Principes ........................................................................................................................ 145 Mise en uvre ................................................................................................................ 146 Lobjet de notification .................................................................................................... 149 Les journaux................................................................................................................... 155 Le contrle de validation deux phases ........................................................................ 156 Conclusions sur le contrle de validation ...................................................................... 157 Les contraintes dintgrit rfrentielle ..............................................................................157 Introduction.................................................................................................................... 157 Mise en uvre ................................................................................................................ 159 Les cls ........................................................................................................................... 161 La gestion ....................................................................................................................... 163 La journalisation............................................................................................................ 164 Exemple en RPG ............................................................................................................ 164 Conclusions .................................................................................................................... 167 Les dclencheurs (triggers) ................................................................................................167 Mise en uvre ................................................................................................................ 168 Le programme dclencheur............................................................................................ 169 Exemple en langage de contrle .................................................................................... 172 Exemple en RPG ............................................................................................................ 173 Remarques...................................................................................................................... 175 Conclusions .................................................................................................................... 176
VI
La sauvegarde et la restauration .........................................................................................176 La scurit ..........................................................................................................................177 Les dispositifs matriels .....................................................................................................178 Le contrle dintgrit (checksum)................................................................................. 179 Les disques miroirs (mirroring) ..................................................................................... 181 Les disques de type RAID 5............................................................................................ 181 Conclusions sur la scurit et lintgrit.............................................................................182 Les principales commandes................................................................................................183 Les principaux menus.........................................................................................................184 6 - SQL/400 .......................................................................................................................185 Introduction ........................................................................................................................185 Lenvironnement SQL........................................................................................................186 Terminologie .................................................................................................................. 187 Le catalogue................................................................................................................... 187 Conventions SQL............................................................................................................ 187 Utiliser une collection ou non ? ..................................................................................... 188 Les lments du langage SQL ............................................................................................189 Les environnements dexcution .................................................................................... 189 Les conventions .............................................................................................................. 191 La dfinition des structures SQL .................................................................................... 191 La gestion des donnes................................................................................................... 195 Les registres spciaux .................................................................................................... 202 Le contrle de validation ............................................................................................... 203 La scurit...................................................................................................................... 203 La connexion une base de donnes loigne............................................................... 204 SQL dans les programmes..................................................................................................205 Principes ........................................................................................................................ 206 Les variables locales ...................................................................................................... 208 Les oprations simples ................................................................................................... 208 Les oprations complexes............................................................................................... 213 Optimisations lies au curseur ....................................................................................... 217 Dplacement contrl dans le curseur........................................................................... 219 SQL dynamique .............................................................................................................. 220 Optimisations .....................................................................................................................226 Loptimiseur ................................................................................................................... 226 Les index ........................................................................................................................ 227 SQL dynamique .............................................................................................................. 227 La commande CHGQRYA.................................................................................................. 227 La commande PRTSQLINF ................................................................................................ 228 Conclusions sur SQL/400...................................................................................................228 Les principaux ordres SQL.................................................................................................229 Les principales commandes................................................................................................230 Les principaux menus.........................................................................................................230 7 - GESTION DE LA BASE DE DONNES .................................................................231
Table des matires
VII
La commande OPNQRYF .....................................................................................................231 Principes ........................................................................................................................ 232 Les principaux paramtres............................................................................................. 235 Les commandes de copie....................................................................................................238 Les commandes de substitution ..........................................................................................242 Ouverture et fermeture contrle des fichiers.....................................................................244 Les rfrences croises.......................................................................................................244 Les principales commandes ........................................................................................... 245 Les API et la base de donnes ............................................................................................245 Les principales commandes................................................................................................246 Les principaux menus.........................................................................................................246 8 - LES BASES DE DONNES DISTANTES ...............................................................247 Les fichiers DDM...............................................................................................................247 DRDA ................................................................................................................................250 Conclusions ........................................................................................................................251 Les principales commandes................................................................................................252 Les principaux menus.........................................................................................................252 CONCLUSIONS...............................................................................................................253 A - FEUILLE DE SPCIFICATION A .........................................................................255 B - LES TYPES DE POSTES DE LA JOURNALISATION ........................................257 C - API ET BASE DE DONNES ..................................................................................261 GLOSSAIRE.....................................................................................................................267 INDEX ...............................................................................................................................277
Avant-propos
Cet ouvrage sadresse toute personne ayant utiliser les donnes de lAS/400. Lutilisateur final dcouvrira comment utiliser SQL, le programmeur trouvera les mots-cls qui lui sont indispensables et le responsable dexploitation pourra optimiser son systme grce une meilleure comprhension des mcanismes de DB2/400. Plusieurs ouvrages comme celui-ci suffiraient peine dcrire toutes les caractristiques de ce SGBD (systme de gestion de base de donnes). Le lecteur trouvera dans ces lignes lessentiel, cest--dire la philosophie gnrale de DB2/400, qui lui permettra de faire les bons choix, au bon moment. De nombreux paramtres et quelques fonctions ont t volontairement omis pour garder une relative concision. Dans la mme optique, les cas particuliers et les contreexemples nont t que rarement traits. La disponibilit dun terminal reli un AS/400 serait un atout supplmentaire pour progresser dans la connaissance de la base de donnes de lOS/400. Les exemples sont simples, choisis gnralement pour leur cot pdagogique. Ils peuvent tre complts et mme optimiss. Pour que ces lignes restent lisibles, nous avons volontairement omis les notions de scurit lies chaque opration. Pour toute action il faudrait rajouter condition davoir les droits suffisants .
Certains exemples ne peuvent tre excuts que si vous possdez des droits levs sur les fichiers. Si vous ne disposez pas dun tel niveau dautorisation, prenez contact avec le responsable de votre systme. Ces lignes sont rdiges alors que lOS/400 est en V3R1M0 (Version 3 Release 1 Modification 0). Il est fort probable que lessentiel de cet ouvrage restera valable au-del des nouvelles volutions de ce systme. Ce travail complte un premier ouvrage du mme auteur intitul Principes gnraux et langage de contrle sur AS/400 (Eyrolles, 2e dition, 1995). De nombreuses rfrences ce livre ont pour objectif dviter les rptitions. Enfin, je voudrais conclure cette liste de remarques par une pense pour ceux qui mont soutenu tout au long de ce travail. Je remercie mes collaborateurs dAlizs Montpellier pour leurs critiques et leurs suggestions. Danile LHERMITE, responsable de la filire Formation AS/400, IBM France, a bien voulu prfacer cet ouvrage. Quelle en soit sincrement remercie.
Nologismes et typographie
Vous trouverez dans cet ouvrage des nologismes issus de termes anglo-saxons ou, le plus souvent, de termes propres lAS/400. Ils appartiennent au langage courant de linformaticien et sont employs chaque fois quils apportent un gain de lisibilit. Un glossaire, la fin de ce volume, reprend ces nologismes et les abrviations employes. Les conventions typographiques retenues sont : Le style de caractre...
CRTPF COMMIT(*NONE)
QSYS create FICH1

EXFMT
ENDPGM
est utilis pour... une commande un paramtre ou une valeur particulire de lOS/400 une bibliothque un terme anglo-saxon un nom propre (dobjet, de variable ou de produit) un programme RPG un programme en langage de contrle
Avant-propos
AVANT-PROPOS ................................................................................................................1 NEOLOGISMES ET TYPOGRAPHIE .............................................................................................2
Chapitre 1
Introduction
Une des raisons du succs de lAS/400 est sa base de donnes intgre. Nous allons dans un premier temps essayer de comprendre pourquoi.
DB2/400 : la base de donnes de lOS/400

DB2/400 est le nom attribu rcemment la base de donnes qui a toujours exist sur lAS/400. Ce nom lui procure une identit quelle navait pas jusque-l car elle est totalement intgre au systme dexploitation OS/400. DB2/400 est un vrai SGBDR (systme de gestion de base de donnes relationnelle) avec les mmes fonctionnalits que ses rivaux, et parfois mme plus. Le principal atout de cette base de donnes rside dans le fait quelle est totalement intgre au systme. Parmi les avantages que cela lui procure nous pouvons relever
:
quelle est systmatiquement jour par rapport lOS/400. Avec chaque nouvelle version du systme est livr DB2/400 au mme niveau
;
quelle est automatiquement installe avec lOS/400 ; il ny a pas dopration particulire raliser pour rendre DB2/400 disponible ;
que cest le seul moyen de grer les donnes. Ainsi, mme si lon travaille en environnement 36, on utilise la base de donnes intgre quelle volue avec le systme. Si celui-ci supporte une nouvelle technologie, elle est automatiquement assimile par la base de donnes
; ;
que certaines fonctions sont directement implmentes au niveau du microcode, ce qui lui procure dexcellentes performances
;
quil ny a pas de nouveau langage apprendre pour grer la base de donnes. Le langage de contrle permet de crer des fichiers, de les sauvegarder, de mettre en place la scurit... ce qui nest jamais le cas avec des SGBD rapports
;
quelle interagit avec lOS/400 comme le ferait une autre fonction systme, cest--dire par lintermdiaire de messages. L aussi il ny a pas besoin de formation complmentaire.
Les caractristiques de DB2/400

SGBD Relationnel
DB2/400 est une base de donnes naturellement multi-utilisateur. Les verrouillages denregistrements sont automatiquement raliss quand il le faut. Les principes mis en uvre pour sa conception sont issus du modle relationnel. Les liens entre les donnes sont tablis dynamiquement, quand on en a besoin. Il ny a aucun pointeur qui cre des liens fixes, souvent difficiles grer, comme dans les SGBD de type rseau ou hirarchique. Il faut en tenir compte lors de la conception de la base de donnes. Il est prudent dutiliser une mthode danalyse de type Merise, par exemple, afin dobtenir une structure dite en troisime forme normale, cest--dire conforme lesprit relationnel. On est ainsi assur quil ny a pas de redondance (duplication inutile de linformation) et que tous les fichiers sont bien structurs. Les termes du modle relationnel ne sont toutefois pas utiliss (sauf dans lenvironnement SQL). On parle, par exemple, couramment de fichier et non de table. Lindpendance entre les programmes et les donnes est assure par des structures qui permettent de voir les donnes sous une certaine forme (tri, slection denregistrements et de zones...) et qui sont nommes fichiers logiques. Sous
1 - Introduction
certaines conditions, le format des donnes peut voluer indpendamment des programmes.
Les interfaces
De nombreuses interfaces nous permettent de grer la base de donnes en fonction de nos besoins et de nos comptences. Nous pouvons, entre autres, citer
:
DFU (Data File Utility) qui permet dagir directement sur les enregistrements dun fichier. Il est considrer comme un utilitaire de bas niveau, rserver au responsable des donnes pour des oprations particulires ou ventuellement au programmeur qui dsire se constituer un jeu de test
;
SQL qui est un langage trs rpandu, couramment associ aux SGBDR. Il permet pratiquement toutes les oprations sur les donnes et sur les fichiers, en interactif, en batch et mme au sein de programmes
;
les commandes de lOS/400 telles que DSPPFM qui affiche le contenu dun fichier ou CRTPF qui le cre
;
Query/400 qui permet dextraire des donnes de la base avec une interface de type menu. Aucun langage nest connatre
;
Office Vision/400 qui peut prendre des informations dans les fichiers pour raliser des mailings
;
PCS/400 et son remplaant Client Access/400 qui autorisent lextraction et la mise jour de donnes partir dun micro-ordinateur
;
et enfin les programmes crits en langage de haut niveau (RPG, Cobol, C...). Il faut noter que le langage de contrle permet dextraire des donnes mais ne peut effectuer de mise jour. LOS/400 propose donc un large ventail doutils permettant la gestion des donnes. Le nombre des fonctions supportes devrait encore crotre au fil des annonces pour conforter la place de lAS/400 comme serveur dentreprise. Chacun doit pouvoir y trouver son compte, en fonction de ses besoins, de ses comptences et du systme dexploitation de son ordinateur.
La scurit
La protection des donnes constitue lun des autres points forts de DB2/400. La scurit est prise en charge par des fonctions microcodes incontournables. Sa mise en place est simple, elle requiert lutilisation de commandes classiques. Elle peut mme devenir draconienne car elle est, sous certaines conditions, conforme la norme C2, une des plus svres en matire de scurit.
1 - Introduction
Lintgrit des donnes est assure par de nombreux dispositifs, matriels ou logiciels, que chacun devra mettre en place en fonction de ses besoins et de ses contraintes.
La base de donnes distribue

Nous entrons dans lre du client/serveur et de la base de donnes rpartie. Il est donc essentiel que DB2/400 puisse tre intgre ces environnements. Cette base nous permet davoir les donnes sur dautres systmes et de les traiter pratiquement comme si elles taient en local. Les environnements distants peuvent tre dautres AS/400, des machines Unix (Risc/6000 dIBM), des mainframes (systmes 370, 390) et mme des micro-ordinateurs.
Conclusions
DB2/400 est la base de donnes multi-utilisateur la plus diffuse au monde (plus de 300 000 exemplaires ce jour). Elle est donc une des rfrences en matire de SGBDR. Aujourdhui, elle dispose de toutes les fonctions indispensables, et mme de bien plus. Elle doit profiter du fantastique essor que lui promettent les nouvelles technologies de lAS/400 (processeurs Risc, multimdia...) et de lengouement pour le client/serveur. IBM a bien lintention de faire de lAS/400 le serveur dentreprise de cette fin de sicle. DB2/400 est lun de ses atouts majeurs.
INTRODUCTION
DB2/400 : la base de donnes de lOS/400 Les caractristiques de DB2/400 SGBD Relationnel Les interfaces La scurit La base de donnes distribue Conclusions
3
3 4 4 6 6 7 7
C
Client Access/400 5
D
DB2/400 3 DFU 5
O
Office Vision/400 5
P
PCS/400 5
Q
Query/400 5
S
scurit 5 SGBDR 3 SQL 5
Chapitre 2
Principes gnraux
Introduction
Pour bien saisir le fonctionnement de la base de donnes, il est important de connatre l'organisation gnrale de l'information pour l'OS/400. Celle-ci tant traite dans l'ouvrage Principes gnraux et langage de contrle sur AS/400 (Eyrolles, 2e dition, 1995), nous ne verrons ici que l'essentiel.
Organisation de l'information
Depuis la version V3R1M0, plusieurs modes de gestion de linformation cohabitent dans lOS/400. Grce lIFS (Integrated File System) et ses commandes associes, une application peut accder des donnes qui sont places dans : les objets ; cest le mode que je qualifie de natif car il existe depuis lorigine de lAS/400 ; les dossiers et documents habituellement utiliss par Office Vision et par la micro-informatique (PCS/400 et CA/400) ; le systme de fichiers destin la compatibilit avec Unix ;
le serveur de fichiers LAN Serveur ; les environnements MS-Dos et OS/2. Dans cet ouvrage, nous ne nous intresserons qu laspect objet de lOS/400 car cest lui qui nous permet de tirer pleinement partie de la base de donnes relationnelle. Tout ce que l'OS/400 peut grer directement est considr comme objet. Ainsi, un programme, un fichier, la description d'une ligne de communication ou d'une imprimante sont des objets. Le type, associ chaque objet, indique quoi correspond cet objet. Par exemple, le type *PGM signifie que cet objet est un programme, *FILE indique qu'il s'agit d'un fichier et *LIND caractrise une description de ligne. A ce jour, il existe plus de 70 types. Chaque objet est organis en deux parties : la premire contient la description de l'objet (son propritaire, sa date de cration, la date de dernire sauvegarde et la commande utilise...) ; la seconde renferme les donnes portes par l'objet (le code excutable pour un programme, les enregistrements pour un fichier...). Chaque objet est rattach une bibliothque. Les bibliothques, qui sont aussi des objets (de type *LIB), sont toutes rattaches la bibliothque fondamentale de l'OS/400 qui est QSYS. Lorganisation des objets nest donc pas une arborescence complexe comme cest le cas pour d'autres systmes (Unix, MS-Dos, OS/2...). Il est important de noter que les objets ne sont pas situs physiquement dans les bibliothques, ces dernires agissant seulement comme des index : pour un nom d'objet et un type, elles renvoient l'adresse relle sur disque. Les objets de type *FILE (les fichiers) contiennent des donnes qui peuvent tre regroupes en membres. Les membres seront utiliss pour ranger les enregistrements correspondant une mme entit : un membre pour les donnes du stock de Paris, un autre pour celui de Montpellier ou bien un membre pour les donnes de chaque anne pour la paie. Nous dtaillerons cette notion fondamentale au niveau des fichiers physiques et logiques. La figure 2.1 rsume l'organisation logique des donnes pour l'OS/400.
Cration d'objets
D'une manire gnrale, les objets sont crs par les commandes de l'OS/400 dont les noms commencent par les lettres CRT, abrviation de Create (crer en anglais).
2 - Principes gnraux
QSYS
*LIB
QGPL
*LIB
COMPTA
PGM1 STOCK
MONTPELLIE PARIS MARSEILLE
*LIB *PGM *FILE
PAYE
*LIB
FICH1
MEMBRE1 MEMBRE2 MEMBRE3
*FILE
FICH2
FICH2
*FILE
Figure 2.1 : organisation logique des donnes pour l'OS/400.

MONTPELLIE, PARIS et MARSEILLE sont les membres du fichier STOCK. MEMBRE1, MEMBRE2 et MEMBRE3 sont les membres de FICH1.
Trois situations principales se prsentent : pour la cration d'un objet standard de l'OS/400 seuls les paramtres de la commande suffisent. Par exemple, la commande CRTDTAARA permet la cration d'une Data area (zone de donnes) ; la cration d'un programme (objet de type *PGM ), ncessite la rdaction d'un source crit dans un langage de programmation (RPG, Cobol, langage de contrle...). Ce source est plac dans un membre (dit membre source) d'un fichier source. La commande de cration (ou compilation) fera rfrence ce membre ; un objet de type fichier (*FILE ) est cr, gnralement, partir d'un membre source crit dans un langage de description de donnes appel DDS (Data Description Specification). Ce langage est constitu de mots-cls que nous dtaillerons plus loin dans cet ouvrage car ils dfinissent l'organisation et la structure des donnes dans les fichiers qui constituent le cur de la base de donnes de l'AS/400. Nous verrons tout au long de cet ouvrage qu'il existe d'autres moyens de crer des fichiers, mais l'utilisation de DDS est le mode naturel.
10
Les fichiers
Gnralits
Les fichiers sont tous les objets de type *FILE. Ils regroupent principalement : les fichiers qui portent les donnes, ce sont les fichiers physiques, ils ont pour attribut PF ; les vues (au sens relationnel) qui sont les fichiers logiques. Leur attribut est LF ; les fichiers d'affichage, qui dfinissent les crans (attribut DSPF) ; les fichiers d'impression, qui dterminent le contenu et les caractristiques des fichiers spoules (attribut PRTF) ; les fichiers DDM (Distributed Data Management) qui procurent un accs aux donnes qui sont sur un autre AS/400 (ou ventuellement sur un systme qui supporte DDM comme lIBM/36 ou lIBM/38) ; et enfin les fichiers de communication (dits ICF) qui ne seront pas traits dans cet ouvrage (attribut ICFF). Cette organisation appelle quelques remarques : de manire naturelle, la gestion des crans est ralise au travers d'un fichier d'affichage (ou fichier cran). Le fichier d'affichage contient toutes les informations relatives aux zones qui apparatront l'cran (noms, emplacements, couleurs, attributs, valeurs constantes...) et l'change hommecran (touches autorises, alarmes sonores, messages d'erreur...). Le programme est totalement dcharg de cette tche ; il n'a pas positionner le curseur dans telle ou telle zone, ou vrifier si une touche de fonction est autorise. Cela simplifie normment le travail de codification du programme source. Le mme principe est utilis pour les fichiers d'impression ; les fichiers base de donnes, c'est--dire les fichiers au sens strict pour d'autres systmes, ou les tables et vues du modle relationnel, sont les fichiers physiques, logiques et DDM. Ils correspondent aux structures de stockage de l'information et aux structures qui permettent laccs ces informations. Dans les programmes, les oprations que l'on peut raliser sur ces fichiers sont identiques celles applicables aux fichiers d'affichage et d'impression car lintgration de la base de donnes dans lOS/400 est totale. Les dclarations, la logique d'utilisation et les ordres de lecture et d'criture sont les mmes pour les
11
fichiers base de donnes, pour les fichiers dimpression et pour les fichiers daffichage. Cela simplifie encore le dveloppement d'applications ; la cration de la plupart de ces objets de type *FILE suit le mcanisme que nous avons dcrit au chapitre prcdent, c'est--dire que ces fichiers sont, de manire naturelle, issus d'un membre source codifi en utilisant le langage DDS ( l'exception des fichiers DDM) ; pour un programme, la gestion des enregistrements de tous ces fichiers s'effectue seulement par des ordres de lecture et d'criture. Tout ce qui est tri, et mme ventuellement slection denregistrement, est mis en uvre directement dans les fichiers.
Description externe
Chaque fichier cr partir de DDS possde, en interne, la description de format, c'est--dire le dtail de chacune des zones qui composent enregistrements de ce fichier. Ainsi, un programme trouvera au dbut de fichiers le masque qu'il faut appliquer sur les donnes pour voir enregistrements. Par exemple : son les ces les
de la position 1 la position 10, il y a la zone NOMCLI de type alphanumrique ; de la 11e la 15e, il s'agit de CODECLI, en numrique, sans positions dcimales ; ... Ces fichiers sont dits description externe, sous entendu externe par rapport au programme, car la description est interne pour le fichier. Quand un programme utilise un tel fichier, il doit seulement le dclarer par la commande adquate du langage (DCLF en langage de contrle, spcification F en RPG...), sans dcrire les zones qui le composent. Lors de la cration d'un programme, le compilateur recopie dans ce dernier les formats des fichiers dclars. Ainsi, le programme dispose du nom, du type, de la longueur et des caractristiques de chaque zone. Ce mcanisme implique que le fichier existe dj lors de la cration du programme, donc : Un fichier doit toujours tre cr avant de compiler un programme qui l'utilise.
12
Les programmes peuvent dcrire en interne les zones qui composent un fichier, soit parce que le fichier n'est pas description externe (pour les fichiers qui viennent de l'IBM/36, par exemple), soit pour pouvoir redfinir certaines caractristiques (le nom essentiellement). Dans ce dernier cas, il est indispensable que les deux formats, celui du fichier et celui dfini dans le programme, soient compatibles (mme longueur et mme type pour chaque zone du programme et du fichier). Dans la suite de cet ouvrage, et sauf contre-indication, nous ne ferons rfrence qu' des fichiers description externe, ce qui correspond la philosophie de la base de donnes de l'OS/400.
L'identificateur de format
C'est donc lors de la compilation qu'un programme reoit le dtail de chacune des zones qui composent les enregistrements d'un fichier. Ces informations sont places dans l'objet de type *PGM et ne seront plus ractualises. Si le format du fichier change (avec lajout dune zone, par exemple), le programme est alors incapable de lire correctement les donnes du fichier. Le masque qu'il a mmoris pour voir les donnes n'est plus adapt. Pour tre sr que le programme et le fichier sont compatibles, le systme s'appuie sur un identificateur de format. Il s'agit d'un code de 13 positions qui identifie de manire unique chaque format. Un algorithme dtermine sa valeur partir du nom des zones, de leur agencement, de leur type et de leur longueur. Si deux formats sont identiques, ils ont le mme identificateur de format. Les actions suivantes modifient l'identificateur de format : renommer une zone ; changer le type, la longueur, ou le nombre de dcimales dune zone ; permuter lordre de zones ; ajouter ou supprimer une zone. Par contre : les oprations sur la cl ; la modification des critres de slection ;
13
la modification des constantes, des commentaires, des couleurs ;
14
et les oprations sur les domaines de validit des zones, n'affectent pas cet identificateur. Lors de la cration d'un programme, le compilateur recopie dans l'objet programme l'identificateur de format du (ou des) fichier(s) dclar(s) dans le source ainsi que la description des zones. A chaque excution de ce programme, le systme vrifie si l'identificateur de format stock dans le programme correspond bien celui du fichier qui est ouvert. En cas d'chec, l'erreur CPF4131 Erreur de niveau... apparat : le fichier et le programme ne sont pas compatibles. Il suffit tout simplement de recompiler le programme pour que cet incident ne se reproduise plus. Il est inutile de recrer le fichier ! Nous verrons au niveau du paramtre LVLCHK de la commande CRTPF comment inhiber cette vrification du systme, en prenant garde aux consquences ventuellement nfastes dune telle action.
Les enregistrements
Rappelons que les fichiers physiques sont les seuls possder rellement des donnes. Les donnes sont stockes dans ces fichiers sous la forme d'enregistrements qui ont la mme organisation car : Dans un fichier physique, tous les enregistrements ont le mme format.
Ajout
En standard, les enregistrements sont ajouts de manire squentielle, les uns la suite des autres : le dernier est plac la fin du fichier. Cette organisation est respecte mme si le fichier a t dcrit avec une cl. En effet la cl agit sur le chemin d'accs qui est une structure indiquant comment les enregistrements doivent tre lus et qui n'affecte en aucune manire la structure physique des donnes (c'est--dire telles qu'elles sont organises sur le disque).
Suppression
Pour le systme, la suppression d'un enregistrement consiste simplement le marquer l'effacement. L'enregistrement est toujours prsent mais ne peut plus tre lu.
15
La suppression d'un enregistrement est irrmdiable, mme si la place qu'occupait cet enregistrement est conserve : il n'y a aucun moyen de le rcuprer. Un trou est ainsi laiss dans le fichier : la place de l'enregistrement est toujours occupe mais il n'est plus disponible et la taille du fichier est toujours identique (figure 2.2). Cette organisation peut tre problmatique pour les fichiers trs actifs, o les suppressions sont frquentes. S'ils sont nombreux, les enregistrements marqus l'effacement peuvent perturber le systme : en tant responsables de l'accroissement de la taille des fichiers ; en provoquant une dgradation des performances. En effet, le systme doit lire un enregistrement avant de savoir s'il est valide (est-il marqu l'effacement ?). Dans le cas d'une lecture squentielle, on imagine aisment le temps perdu traiter les enregistrements supprims.
Suppression du 4 enregistrement
e
Ajout dun enregistrement
1 2 3 4 5 6 7 8
Enregistrement Effacement
1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8 9
NOUVEAU
Figure 2.2 : suppression d'un enregistrement dans un fichier physique. Reprsentation du fichier avant et aprs suppression du 4e enregistrement. Aprs suppression, cet enregistrement n'est plus disponible, la position relative des autres enregistrements est inchange. Un nouvel enregistrement sera plac la fin du fichier, la place libre n'tant pas rcupre en standard.
16
Il existe au moins trois solutions pour pallier cet inconvnient : en grant soi-mme, par programme, les enregistrements dtruits et en plaant les nouveaux la place des anciens, par mise jour. Jusqu' l'apparition de la version 2, cette mthode avait de nombreux adeptes ; depuis la version 2, le paramtre REUSDLT de la commande CRTPF nous permet de demander au systme de placer un nouvel enregistrement la place d'un autre marqu l'effacement. Le systme maintient alors une table des "places libres". Nous le verrons au chapitre consacr cette commande ; enfin, la commande RGZPFM (reorganize physical file member), opre un compactage des enregistrements des membres d'un fichier. Les enregistrements valides sont dcals pour occuper la place de ceux marqus l'effacement. Les "trous" sont ainsi combls (figure 2.3). Cette commande a d'autres fonctions telle que la rorganisation des chemins daccs. L'objet fichier tant bloqu pendant tout le compactage, cette fonction doit donc tre lance en dehors des priodes d'activit des applications qui utilisent ce fichier. L'emploi priodique de cette commande est vraiment ncessaire pour les fichiers forte activit (nombreuses suppressions et insertions). Il est essentiel de procder une sauvegarde du fichier avant dexcuter cette commande.
RGZPFM
1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8
Figure 2.3 : compactage d'un fichier par la commande RGZPFM.
Liens avec la programmation
17
Il est important de dfinir les principes lmentaires de la programmation avec les fichiers pour pouvoir apprhender correctement les exemples prsents tout au long de cet ouvrage. Dans un programme, la gestion des fichiers est relativement simple. Elle se compose essentiellement de deux parties, quel que soit le type de fichier : la dclaration ; les ordres de lecture/criture. La dclaration suffit provoquer louverture automatique du fichier, la fin du programme le fermant de manire implicite. Nous rserverons les ordres explicites d'ouverture et de fermeture de fichiers des cas particuliers. Toutes les zones dcrites dans un fichier sont connues du programme sous la forme de variables qui ont le mme nom que ces zones. Au dbut de la compilation, les caractristiques de chaque zone sont ramenes en tte du programme, si bien que celui-ci dispose de toutes les informations ncessaires pour initialiser ces variables : nom, type, longueur. Il en est de mme pour les indicateurs des fichiers d'affichage et d'impression. La gestion d'un enregistrement s'effectue par l'intermdiaire d'un format. Le programme va donc crire, ou lire, des formats entiers. Quelques exemples en langage de contrle et en RPG vont illustrer ces principes.
Exemples en langage de contrle

Le langage de contrle permet de grer les fichiers en lecture uniquement, l'exception des fichiers d'affichage dont il peut lire les formats pour rcuprer les informations saisies par un utilisateur. De ce fait, on ne peut employer ce langage pour crire des programmes chargs de la cration ou de la mise jour d'enregistrements, ou encore destins gnrer des tats imprimer. Une deuxime contrainte est attache au langage de contrle : un programme ne peut utiliser au maximum qu'un seul fichier.
Utilisation d'un fichier physique ou logique

Lexemple 2.1 dcrit l'architecture classique d'un programme en langage de contrle (dit CLP) lisant un fichier base de donnes (commande RCVF) :
PGM
18
DCLF(FICH1) /*dclaration du fichier, le fichier sera ouvert et le */ /*premier enregistrement prt tre lu*/ DCL ... /*dclaration des variables*/ LECT : RCVF RCDFMT(FMT1) /*lecture d'un enregistrement du fichier, */ /*FMT1 est le nom du format du fichier FICH1*/ MONMSG MSGID(CPF0864) EXEC(GOTO FIN) /*test de fin de fichier*/ .../*traitement de l'enregistrement lu*/ GOTO LECT : /*lecture de l'enregistrement suivant*/ FIN : .../*traitement de fin de fichier*/ ENDPGM
Exemple 2.1 : architecture dun programme CLP utilisant un fichier base de donnes. Le message CPF0864 est renvoy par le systme quand le programme essaye de lire un enregistrement au-del de la fin du fichier. Il faut donc lintercepter par la commande MONMSG pour dtecter la fin de fichier.
L'exemple 2.2 dcrit un programme qui calcule la somme de la zone SOLDE pour tous les enregistrements du fichier. DDS du fichier FICH1
R NOM FMT1 NUMCLI SOLDE FONCTION 10 7
Ce fichier contient un format FMT1 qui est constitu des zones NUMCLI, de type Alphanumrique, de longueur 10, et SOLDE de type Dcimal condens de 7 dont 2. Programme en langage de contrle
PGM DCLF(FICH1) /*dclaration du fichier, le fichier sera ouvert et le */ /*premier enregistrement prt tre lu*/ DCL VAR(&TOTAL) TYPE(*DEC) LEN(9 2) VALUE(0) /*dclaration de la variable TOTAL et initialisation 0*/ LECT : RCVF RCDFMT(FMT1) /*lecture d'un enregistrement du fichier, */ MONMSG MSGID(CPF0864) EXEC(GOTO FIN) /*test de fin de fichier*/ CHGVAR &TOTAL (&TOTAL + &SOLDE) GOTO LECT : /*lecture de l'enregistrement suivant*/ FIN : .../*traitement du total et de fin de fichier*/
19
ENDPGM
Exemple 2.2 : utilisation d'un fichier base de donnes en langage de contrle.
20
Utilisation d'un fichier d'affichage

Un format d'un fichier d'affichage peut tre lu (commande RCVF), crit (SNDF) ou mme crit et lu en une seule opration (SNDRCVF). Le programme et le fichier d'affichage vont changer des informations par l'intermdiaire d'indicateurs. Il s'agit de structures lmentaires qui sont soit enfonction (ou vrai) soit hors-fonction (ou faux). Il y en a 99 notre disposition, nomms 01 99. Dans l'exemple suivant, l'indicateur 03 a t associ la touche de fonction F3 dans le fichier d'affichage. Si l'utilisateur appuie sur F3, l'indicateur 03 est mis en-fonction. Ainsi, les indicateurs sont utiliss pour informer le programme quun vnement vient de se produire. En langage de contrle, l'indicateur 03 est associ une variable nomme &IN03, et dune manire gnrale, lindicateur XX est associ la variable &INXX.
PGM DCLF(ECR1) /*dclaration du fichier, le fichier est ouvert*/ DCL ... /*dclaration des variables*/ LECT : SNDRCVF RCDFMT(FMT1) /* affichage d'un cran et lecture des */ /*informations saisies par l'utilisateur*/ IF &IN03 GOTO FIN /*la condition de fin est ralise*/ .../*traitement de l'enregistrement lu*/ GOTO LECT : /*raffichage de l'cran*/ FIN : .../*traitement de fin de programme*/ ENDPGM
Exemple 2.3 : architecture dun programme CLP utilisant un fichier daffichage
L'exemple 2.4 dcrit un programme qui gre le choix d'un utilisateur. DDS du fichier d'affichage ECR1
R NOM FMT1 LG DEC U LIG COL FONCTIONS CA03(03 'fin') 1 30 'MENU GENERAL 10 30 '1-Comptabilit' 12 30 '2-Paie' 14 30 '3-Commercial' 16 30 'Rponse :' 16 40 RANGE(1 3) 24 10 'F3 :Fin'
REP
21
Cet cran propose un choix l'utilisateur qui rpondra soit par une valeur comprise entre 1 et 3 dans la zone REP, soit en appuyant sur F3, auquel cas l'indicateur 03 sera mis en-fonction. Affichage de lcran ECR1
MENU GENERAL 1-Comptabilit 2-Paie 3-Commercial Rponse : F3 : Fin
Programme en langage de contrle

PGM DCLF(ECR1) /*dclaration du fichier*/ LECT : SNDRCVF RCDFMT(FMT1) /*Affichage d'un cran et lecture des informations saisies par l'utilisateur*/ IF &IN03 GOTO FIN /*la condition de fin est ralise (appui sur F3)*/ ELSE IF (&REP = 1) CALL COMPTA ELSE IF (&REP = 2) CALL PAIE ELSE IF (&REP = 3) CALL COMMERCIAL GOTO LECT : /*raffichage de l'cran de choix*/ FIN : .../*traitement de fin de programme*/ ENDPGM
Exemple 2.4 : programme en langage de contrle de gestion d'un cran.
Exemples en RPG
Le RPG, au mme titre que les autres langages de haut niveau tels que le Cobol, le PL1, le Pascal ou le C, permet l'criture dans les fichiers. Il est donc utilis pour codifier les programmes qui doivent ajouter ou modifier des enregistrements. Le RPG/400 est un compilateur disponible depuis lapparition de lAS/400. Il est adapt aux programmes que je qualifie de type gestion et qui correspondent au domaine de prdilection de lAS/400 dorigine. Le RPG IV est un compilateur, apparu avec la V3R1M0 de lOS/400, qui sinscrit totalement dans le cadre de lILE. Il correspond une volution du RPG/400 et apporte une plus grande souplesse dans le dveloppement. Il supporte les nouvelles
22
fonctions de lOS/400 telles que les nouveaux types (Date, Heure et Horodatage) et la modularit. A ce jour, ces deux compilateurs sont contenus dans le logiciel sous licence RPG. Les exemples de cet ouvrage seront, selon les besoins, prsents dans lun ou lautre de ces langages. Les programmes que nous verrons utilisent la logique libre, ils ne s'appuient donc pas sur le cycle logique qui traite de manire automatique les fichiers. Seules les fonctions de base sont dcrites dans cet ouvrage. Pour un complment d'information nous renvoyons l'ouvrage de C. Gauthier : RPG/400.et environnement de dveloppement (Eyrolles, 1993). A l'origine (dans les annes 60), les programmes taient codifis sur des cartes perfores. Le langage RPG en a hrit une certaine rigueur dans la codification : chaque ligne de code appartient un certain type (la spcification) qui dpend de la fonction excuter par le programme. Une spcification de type F correspond la dclaration d'un fichier, une spcification C dcrit un traitement (une instruction excutable) ; chaque spcification impose un format strict pour la codification des instructions sur cette ligne. Pour une spcification F, par exemple, le nom du fichier doit tre situ partir de la colonne 7.
La spcification F
La spcification F permet de dcrire les fichiers utiliss par un programme. Nous allons rapidement prsenter ses caractristiques. RPG/400 Colonne Libell 6 Dfinition de la spcification 7-14 Nom du fichier 15 Type douverture du fichier Valeurs
F I : en lecture O : en criture U : en mise jour C : combin (pour P : primaire S : secondaire F : logique libre F : interne
les crans)
16
Mode de traitement
19
Description du fichier
23
31 40-46
Utilisation de la cl Type de fichier
66 71-72 RPG IV
Ajout denregistrement
compte de la cl blanc : pas dutilisation de la cl DISK : base de donnes PRINTER : impression WORKSTN : cran A : ajouts autoriss
E : externe K : prise en
Contrle de louverture et de la UC : par lutilisateur fermeture des fichiers blanc : par le programme
Colonne Libell 6 Dfinition de la spcification 7-16 Nom du fichier 17 Type douverture du fichier
Valeurs
F I : en lecture O : en criture U : en mise jour C : combin (pour les crans) P : primaire S : secondaire F : logique libre F : interne E : externe A : ajouts autoriss K : prise en compte de la cl
18
Mode de traitement
22 20 34 36-42
Description du fichier Ajout denregistrement Utilisation de la cl Type de fichier
blanc : pas dutilisation de la cl DISK : base de donnes PRINTER : impression WORKSTN : cran
44-80
Mots-cls
Utilisation d'un fichier physique ou logique

Lutilisation des fichiers base de donnes est extrmement simple en RPG. Les dclarations sont effectues laide des spcifications F. Quelques codes oprations permettent la lecture, lcriture et la mise jour denregistrements. Voici quelques exemples en RPG/400. Les oprations sont effectues sur le fichier MODELE, description externe, et qui a pour format FMT. Il est trait en logique libre.
24
Lecture dun enregistrement

...... *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 FMODELE IF E C*TRAITEMENT ........ C*........ C*LECTURE DUN ENREGISTREMENT C READ FMT C... C MOVE *ON DISK
90 *INLR
Modification dun enregistrement

...... *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 FMODELE UF E DISK C*TRAITEMENT ........ C*LECTURE DE LENREGISTREMENT C READ FMT C*MODIFICATION DES ZONES C... C*MISE A JOUR DUN ENREGISTREMENT C UPDATFMT C... C MOVE *ON *INLR
90
Ajout dun enregistrement

...... *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 FMODELE O E C*TRAITEMENT ........ C*........ C*AJOUT DUN ENREGISTREMENT C WRITEFMT C... C MOVE *ON DISK A
*INLR
Lecture sur cl
...... *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 FMODELE IF C*TRAITEMENT C*........ C*LECTURE DU C C... C E ........ K DISK
PREMIER ENREGISTREMENT QUI A POUR VALEUR DE CLE ZONE1 ZONE1 CHAINFMT 90 MOVE *ON *INLR
Les DDS
Introduction
25
Les DDS (Data Description Specification) constituent un langage de description de fichiers. A l'image du RPG, les DDS doivent tre codifies rigoureusement, chaque information tant place en un endroit prcis. Les spcifications A dfinissent la structure de chacune des lignes du source en imposant la colonne o doit tre place chaque information. Toutes les DDS (de tous les fichiers) sont codifies avec cette spcification. Une hirarchie est tablie dans les DDS. Selon la ligne o est codifie une information, son impact sera sur tout le fichier ou limit une zone. Malgr ces rgles en apparence rigides, la codification des DDS est aise, notamment grce lditeur de source SEU qui propose une invite nous permettant dignorer lemplacement prcis de chaque information. De plus, il vrifie la syntaxe et vite, ainsi, de nombreuses erreurs de codification.
La spcification A
Vous trouverez en annexe A une feuille de spcification A. Tout au long de cet ouvrage, nous allons dtailler les principales valeurs que peuvent prendre chacune de ses colonnes. Cette spcification est utilise pour tous les types de fichiers (physiques, logiques, d'affichage, d'impression...). Les sources des objets de type *FILE ont donc tous la mme organisation. Voici les principales colonnes : Position
6 7
Longueur
1 1
Nom
Spcification
Commentaires
17
19
10
Indique la spcification utilise. La valeur est obligatoire, un blanc est autoris. Commentaire Une astrisque indique au compilateur d'ignorer la ligne. Il s'agit donc d'un commentaire. Type Prcise quoi correspond le nom spcifi en colonne 19 : R : pour un format ; K : pour dfinir la cl (ou une partie de la cl) ; S ou O : pour les critres de slection ou d'omission ; un blanc pour tout le reste. Nom Nom du format, de la zone ou de la cl (selon la lettre codifie en colonne 17).
A
26
30 35 36 38
5 1 2 1
39
42
45
36
Longueur Longueur de la zone. Type de zone Type de la zone. Dcimales Nombre de positions dcimales (pour les zones numriques). Usage Prcise l'utilisation de cette zone (par rapport au programme) : I : la zone est utilise en entre (le programme peut la lire mais ne peut pas la mettre jour) ; O : la zone est utilise en sortie ; B : la zone est utilise en entre et en sortie. H : la zone est cache. Ligne Indique quelle ligne doit tre place cette zone (pour fichier d'affichage et d'impression). Colonne Indique quelle colonne doit tre place cette zone (pour fichier d'affichage et d'impression). Fonction C'est ce niveau que sont codifis les mots-cls des DDS et les constantes.
Il reste noter que certaines colonnes ne sont applicables qu certains types de fichiers. Colonne et ligne, par exemple, servent indiquer o doit tre place une information : elles sont inoprantes pour un fichier base de donnes.
La hirarchie
Une hirarchie est impose dans les DDS (figure 2.4). Les premiers mots-cls qui doivent tre codifis sont ceux de niveau Fichier. Ils ont un impact sur la totalit du fichier. Un R en colonne TYPE (position 17) permet de saisir les mots-cls de niveau Format. Ils ont une action sur tout le format. Les zones et les constantes sont dfinies la suite, au niveau Zone. Enfin, et selon le type de fichier, on trouve les mots-cls de niveau Cl et (ou) de niveau Slection/Omission.
27
NOM
FMT1 1 NUMCLI ZONE1 ZONE2 5 0 5 5 35 10 22
K S
FONCTION MOT1 MOT2 MOT3 TEXT(Commentaire) Constante COLOR(WHT) Constante2 MOT4 MOT5 COMP(EQ X)
Niveau Fichier Niveau Format Niveau Zone Niveau Cl Niveau Slection
Figure 2.4 : la hirarchie dans la codification des DDS. Le fichier dcrit ici est thorique et ne correspond aucune ralit.
Exemples
Les exemples suivants montrent les DDS d'un fichier physique (exemple 2.5) et d'un fichier d'affichage (exemple 2.6). Nous verrons les principaux mots-cls concernant ces DDS dans les chapitres suivants, il sagit seulement ici de prsenter lorganisation des sources de fichiers.
NOM R FMT1 NOMCLI NUMCLI RUE CODPOS CODE 15 5 25 5 3 A P A A A LG TYPE DEC FONCTIONS UNIQUE TEXT(Format du fichier + physique) REFSHIFT(X) RANGE(10000 50000)
VALUES(CPT 30J 60J + VIR) REFSHIFT(X)
NUMCLI
Exemple 2.5 : les DDS d'un fichier physique (les colonnes inutiles ne sont pas reprsentes).
NOM LGR TYPE DEC USAGE LIGNE COL FONCTION INDARA CA03(03 Fin) TEXT(Saisie client) CF10(10 impression) 34 SAISIE CLIENT COLOR(WHT) 10 Numro du client : 25 TEXT(Affichage client)
FMT1 1 3 3
NUMCLI FMT2
28
NOMCLI SOLDE FMT3
15 7
A P 2
O O
5 5 7 7 24
10 25 10 25 10
CF10(10 impression) Nom du client Solde : TEXT(Touches de fonction) F3=Fin F10=Impression
Exemple 2.6 : les DDS d'un fichier d'affichage (les colonnes inutiles ne sont pas reprsentes).
Les types de donnes

La base de donnes de lOS/400 supporte diffrents types de donnes. Cest la colonne TYPE DE DONNEES (en position 35 des DDS) qui prcise le type de la zone.
29
Voici les principales valeurs : Type P A S B F H L T Z Signification Dcimal condens Alphanumrique Dcimal sign Binaire Dcimal en virgule flottante Hexadcimal Date Heure Horodatage
Habituellement, lOS/400 utilise le type Alphanumrique pour les zones contenant des caractres et le type Dcimal condens pour les valeurs numriques. Ces types sont pris par dfaut lorsquaucune indication nest donne en position 35. Ainsi : Si aucune information nest codifie en colonne TYPE DE DONNEES, la zone est considre comme tant de type Alphanumrique si elle ne possde pas de donnes dcimales, et de type Dcimal condens sinon. Les zones de type Alphanumrique sont structures simplement : chaque caractre occupe un octet. Une zone dfinie avec une longueur de 10 occupe dix octets mme si linformation contenue dans cette zone est plus courte. Le calcul est un peu plus complexe pour les zones de type Dcimal condens. Il doit intgrer les lments suivants : une position numrique est codifie sur 4 bits (soit un demi-octet) ; la virgule nest pas stocke ; 4 bits sont rservs pour le signe ; un nombre entier doctets doit tre utilis. Une zone de longueur 5 dont 2, cest--dire 5 positions dont 2 dcimales (par exemple +123,45), occupe 3 octets en mmoire : un demi-octet pour le signe et 5 demi-octets pour la reprsentation du nombre soit en tout 6 demi-octets (figure 2.5).
30
Pour une zone de longueur 4 dont 2, on trouve 2 octets et demi, soit 3 octets en tout car il y a un nombre entier doctets occups. Un demi-octet est donc inutilis.
(5 2) +123,45 +12345
1 octet
(4 2) +12,34 +1234
1 octet
Figure 2.5 : reprsentation de la structure dune zone en Dcimal condens. Nous remarquons quune zone de longueur 5 occupe 3 octets comme une zone de longueur 4 (quel que soit le nombre de dcimales).
On a donc toujours intrt choisir des valeurs impaires pour les longueurs des zones en Dcimal condens.
Conclusions
Les principes que vous venons de voir font que les dveloppeurs AS/400 ont une excellente productivit. Les programmes sont limits la description des traitements proprement dits. Tout ce qui est gestion des crans, gnration des tats imprimer et bien dautres choses encore est gr par le systme, librant ainsi le programme de ces tches. La base de donnes est totalement intgre lOS/400 ce qui fait que la gestion des donnes dans les programmes est la mme que ce soit pour les fichiers, les impressions ou les crans. Le travail dapprentissage en est singulirement raccourci. Enfin, nous avons pu voir que de nombreux mcanismes sont mis en oeuvre pour assurer la scurit et lintgrit des donnes ; nous en verrons bien dautres.
31
PRINCIPES GENERAUX...................................................................................................7 INTRODUCTION .......................................................................................................................7 Organisation de l'information ............................................................................................7 Cration d'objets ................................................................................................................8 LES FICHIERS .........................................................................................................................10 Gnralits .......................................................................................................................10 Description externe ..........................................................................................................11 L'identificateur de format.................................................................................................12 LES ENREGISTREMENTS.........................................................................................................14 Ajout .................................................................................................................................14 Suppression ......................................................................................................................14 LIENS AVEC LA PROGRAMMATION .........................................................................................16 Exemples en langage de contrle.....................................................................................17 Exemples en RPG.............................................................................................................21 LES DDS...............................................................................................................................24 Introduction......................................................................................................................24 La spcification A .............................................................................................................25 La hirarchie....................................................................................................................26 Exemples ..........................................................................................................................27 Les types de donnes ........................................................................................................28 CONCLUSIONS .......................................................................................................................30
32
B
bibliothque 8
C
Cration 8
D
DCLF 11 DDM 10 DDS 9
F
fichier 10 fichier d'affichage 10 fichier d'impression 10 fichier logique 10 fichier physique 10
I
IFS 7
L
LAN Serveur 7
M
membre 8
O
OS/2 8
R
RCVF
18 15
RGZPFM
S
SNDF
18 18
SNDRCVF
T
type 8
Chapitre 3
Les fichiers physiques
Les fichiers physiques sont les objets de la base de donnes de l'OS/400 qui servent au stockage des donnes. Un soin tout particulier doit tre accord leur structure et leur organisation. Il faut notamment garder l'esprit que cette base de donnes est relationnelle. On tirera pleinement parti de sa puissance si l'on organise les donnes en respectant les prceptes du Modle Relationnel (troisime forme normale...). Il est gnralement indispensable de procder une phase d'analyse des donnes (MCD de Merise, par exemple) avant de codifier les fichiers physiques. Depuis lorigine de lAS/400, les DDS constituent le mode naturel de cration des fichiers physiques. Mais, SQL, en se positionnant comme un produit de plus en plus stratgique pour cette plate-forme, devient lun des principaux langages de gestion des donnes ; il permet de crer des fichiers physiques appels tables. Enfin, nous citerons pour mmoire le produit IDDU, assez peu utilis, qui permet de crer des fichiers partir dun dictionnaire. Dans ce chapitre, nous ne dtaillerons que les commandes et les fonctions standard de lOS/400. Plus loin dans cet ouvrage, nous verrons ce qui concerne le langage SQL.
30
Les tapes de la cration d'un fichier physique par DDS

Un fichier physique description externe est construit en deux tapes. Dans un premier temps, il faut codifier un membre source avec SEU, en utilisant les DDS ; cette tape permet de dfinir la structure des donnes l'intrieur du fichier. Ensuite, ce source doit tre cr ou compil ( l'image des programmes) par la commande CRTPF. Les nombreux paramtres de cette commande dfinissent les caractristiques gnrales de l'objet fichier (figure 3.1).
DESCRIPTION
NOMCLI 15 NUMCLI 5 0 SOLDE 8 2
R FMT1 NOMCLI NUMCLI SOLDE
15 5 0 8 2
CRTPF
Membre source Type PF

Type : *FILE Attribut : PF
Figure 3.1 : les tapes de la cration d'un fichier physique.
Dans un premier temps, nous allons voir la codification des fichiers physiques description externe grce aux DDS. Puis, nous verrons les principaux paramtres de la commande CRTPF. La gestion des membres sera aborde ensuite pour terminer avec les principales commandes de gestion des fichiers physiques.
La codification des fichiers physiques

La codification des fichiers physiques permet de dfinir la structure des fichiers description externe. Elle s'appuie sur les DDS dont nous avons nonc les principes au chapitre prcdent. La prsentation des DDS se fait habituellement sous la forme d'une liste exhaustive de mots-cls rpartis en niveaux (Fichier, Format, Zone et Cl). Nous abandonnerons cette dmarche en prfrant traiter des thmes particuliers qui regroupent souvent plusieurs mots-cls. En fin de chapitre figure une description sommaire de tous les mots-cls.
3 - Les fichiers physiques
31
Principes
L'organisation des DDS dans un fichier physique est prsente dans la figure 3.2.
NOM FONCTION REF(DICT1) UNIQUE ALTSEQ(TABLE1) TEXT(FORMAT1) RANGE(10000 50000) COLHDG(Numro de client) CHKMSGID(MSG0001 COMPTA) REFSHIFT(X) COLHDG(Nom de client) DESCEND
Niveau Fichier Niveau Format Niveau Zone
FMT1 NUMCLI
NOMCLI K NUMCLI
15
Niveau Cl
Figure 3.2 : organisation des DDS pour un fichier physique.
Le dictionnaire
Pour rpondre des exigences de gain de productivit, il est possible de dfinir de manire unique l'ensemble des zones d'une application dans un dictionnaire (aussi appel rpertoire ou fichier de rfrence de zones). Chaque zone est dcrite dans ce dictionnaire le plus prcisment possible avec son type, sa longueur, ses contraintes, son en-tte de colonne... Lors de la codification d'un fichier physique, il suffira d'indiquer au compilateur qu'il faut aller chercher la description des zones dans le dictionnaire spcifi au niveau des mots-cls REF et REFFLD. REF est un mot-cl de niveau Fichier. Il permet de dfinir le nom du dictionnaire pour les zones en regard desquelles un R a t codifi en colonne REFERENCE (position 29). Un seul dictionnaire peut ainsi tre dfini pour un fichier ; REFFLD s'applique au niveau Zone. Il fait rfrence une zone dans un dictionnaire, il est utilis dans trois cas : si la zone qui sert de rfrence n'a pas le mme nom que la zone que l'on est en train de dcrire ; si le dictionnaire qui contient la zone est diffrent de celui cit dans le mot-cl ref ; enfin, si la zone de rfrence appartient au source que l'on est en train de codifier.
32
L'exemple 3.1 rsume l'utilisation de ces deux mots-cls.

NOM R FORMAT1 NOMCLI NUMCLI SOLDE CREDIT LG DEC FONCTION REF(BIB1/DICT1)
R R 8 R 2
REFFLD(NUMERO DICT2) REFFLD(SOLDE *SRC)
Exemple 3.1 : utilisation d'un dictionnaire pour un fichier physique. NOMCLI fait rfrence la zone du mme nom situe dans le dictionnaire DICT1 de la bibliothque BIB1. NUMCLI fait rfrence la zone NUMERO du dictionnaire DICT2 de la liste de bibliothque. CREDIT fait rfrence SOLDE qui est dcrit dans ce source.
Nature du dictionnaire
Un dictionnaire n'est rien d'autre qu'un fichier physique classique . C'est un choix personnel que de le nommer dictionnaire car aucune commande ne permet de transformer un fichier en dictionnaire. N'importe quel fichier physique peut servir de rfrence en tant cit dans les mots-cls REF ou REFFLD. Souvent, les dveloppeurs (ou les analystes) dcident de crer un fichier qui contient la liste exhaustive de toutes les zones d'une application. Ce fichier ne possdera ni donne, ni membre. Il est cr uniquement pour servir de rfrence ; c'est cet objet que l'on nomme dictionnaire .
Remarques
Il est important de bien comprendre le mcanisme mis en place autour du dictionnaire pour en voir les limites. La rfrence un dictionnaire est utilise uniquement au moment de la cration d'un fichier physique. Le compilateur va chercher la description des zones concernes et cre l'objet de type *FILE. Par la suite, il n'y a plus de lien entre le dictionnaire et le fichier physique. La modification d'une zone dans le dictionnaire n'aura aucune incidence sur les fichiers qui ont t crs en faisant rfrence cette zone. Si l'on dsire que cette modification soit gnrale, il faut recompiler tous ces fichiers pour que la nouvelle description de zone soit prise en compte (attention la perte des donnes).
33
C'est ce jour une des limites de la notion de dictionnaire sur l'AS/400. Des outils peuvent tre crits pour pallier cette insuffisance en utilisant les API ou les commandes de gestion des rfrences croises.
Les cls Mise au point

Il est important de rappeler que, dans un fichier physique, les enregistrements sont rangs dans l'ordre de leur arrive. Le premier enregistrement cr est le premier dans le fichier, le dernier est plac la fin. La possibilit de dfinir une cl pour ces fichiers ne change en rien cette organisation. Les enregistrements sont toujours rangs en fonction de leur ordre d'arrive. Mais, si une cl est dfinie, un chemin d'accs est cr et permet de voir les enregistrements comme tris. Les enregistrements d'un fichier physique sont toujours rangs en fonction de leur ordre d'arrive. Si une cl est dfinie pour ce fichier, un chemin d'accs permet de voir ses enregistrements comme s'ils taient tris. Les zones qui composent la cl sont cites dans l'ordre, au niveau Cl, prcdes d'un K en colonne TYPE (position 17). Elles doivent tre dcrites au niveau Zone. L'exemple 3.2 prsente les DDS d'un fichier physique qui a une cl dfinie sur trois zones. Les enregistrements seront vus tris sur la zone NOCLI, puis sur MONTANT et enfin sur DATE.
NOM R FMT1 NOCLI DATE CDE MONTANT K NOCLI K MONTANT K DATE LG DEC REF(DICT1) R R R R FONCTION
Exemple 3.2 : codification de la cl dans un fichier physique.
Les principaux mots-cls de niveau Cl
34
Plusieurs mots-cls de niveau Cl nous permettent de dfinir l'ordre de tri pour chaque critre (exemple 3.3). En voici les principaux : ABSVAL : les enregistrements apparaissent tris selon la valeur absolue de cette zone ; DESCEND : les enregistrements apparaissent tris selon la valeur dcroissante de cette zone (la plus grande valeur sera renvoye en premier, la plus petite en dernier). Par dfaut le tri est effectu selon la valeur croissante.
R NOM FMT1 NOCLI DATE MONTANT DATE MONTANT DATE 941104 941105 941105 941105 941105 CDE 12354 12355 12356 12358 12354 LG 2 6 7 DEC FONCTION
0 0 DESCEND ABSVAL MONTANT -18000 10000 13000 12000 -11000 NOCLI 20 10 70 60 50 DATE 941105 941105 941105 941105 941104 MONTANT 10000 -11000 12000 13000 -18000
K K
NOCLI 50 20 60 70 10
Exemple 3.3 : mise en uvre des mots-cls de niveau Cl lors de la codification d'un fichier physique. Les enregistrements apparatront tris sur DATE, la plus forte valeur tant renvoye en premier, puis pour une mme date, selon la valeur absolue de MONTANT. Le tableau de gauche montre les donnes telles qu'elles sont organises dans le fichier, le tableau de droite prsente les enregistrements dans l'ordre o ils apparatront lors d'une lecture sur cl.
Les mots-cls de niveau Fichier

Les mots-cls de niveau Fichier dfinissent les caractristiques gnrales de la cl : UNIQUE : si ce mot-cl est codifi, le fichier ne pourra avoir deux enregistrements qui ont mme valeur de cl. Lors d'une tentative d'insertion d'un enregistrement dont la valeur de cl existe dj dans le fichier, le systme enverra un message d'erreur au programme ; LIFO : (Last In First Out) les enregistrements ayant mme valeur de cl seront vus dans l'ordre dernier arriv, premier lu. La valeur par dfaut est FIFO (First In First Out) premier arriv, premier lu.
Squence de tri
35
Lors de la constitution d'un chemin d'accs sur une cl partir de zones de type Alphanumrique, le tri standard s'effectue en fonction de la reprsentation hexadcimale. Il distingue donc les minuscules et les majuscules, les minuscules tant places avant, les majuscules aprs.
36
Voici une srie d'enregistrements avant et aprs le tri :

Avant tri CCC aaa AAA BBB ccc bbb Aprs tri aaa bbb ccc AAA BBB CCC
Les tables de conversion permettent de redfinir lordre du tri en donnant un certain poids chaque caractre (sous la forme d'une valeur hexadcimale). C'est cette valeur qui est utilise lors du tri. Ainsi, les caractres minuscules et majuscules peuvent avoir le mme poids (a et A sont gaux devant le tri). Dans ce cas la squence ci-dessus deviendrait :
Avant tri CCC aaa AAA BBB ccc bbb Aprs tri aaa AAA BBB bbb CCC ccc
La table QCASE256 de QUSRSYS est fournie cet effet. Il nexiste pas de commandes qui permettent laffichage du contenu dune table. Pour voir le poids de chaque caractre devant le tri on peut soit simuler une cration de table par la commande :
CRTTBL TBL(TEST) SRCFILE(*PROMPT) BASETBL(*LIBL/QCASE256)
soit utiliser la commande WRKTBL puis loption 5 en regard de la table choisie. Vous pourrez ainsi noter que pour la table QCASE256, le caractre de valeur hexadcimale X81, c'est--dire a, possde la valeur XC1 pour le tri, la mme que A. Les lettres A et a ont donc le mme poids devant le tri, pour cette table. Le mot-cl ALTSEQ, de niveau Fichier, associe une table de translation la totalit des zones de type Alphanumrique composant la cl d'un fichier. NOALTSEQ (au niveau Cl) dsactive la table de translation pour la zone en regard de laquelle il est codifi (exemple 3.4). La table ainsi dfinie est recopie dans la partie descriptive du fichier. La commande DSPFD permet de le vrifier.
37
Les paramtres SRTSEQ et LANGID de la commande CRTPF apportent des fonctionnalites comparables.
NOM FONCTION REF(DICT1) ALTSEQ(TABLE1) R R R R NOALTSEQ
K K K
FMT1 NOMCLI PRODUIT TYPE MONTANT NOMCLI PRODUIT TYPE
Exemple 3.4 : mise en uvre d'une table de translation pour un fichier physique. La table TABLE1 de la liste de bibliothque est utilise pour les zones cls de type Alphanumrique, sauf pour la zone PRODUIT.
Liens avec les fichiers d'affichage

Les DDS nous permettent de placer dans un fichier physique, ou dans un dictionnaire, certains mots-cls associs des zones, afin de simplifier et d'homogniser le travail de codification des fichiers d'affichage. Lors de la dfinition d'une zone d'un fichier d'affichage, on peut faire rfrence une zone d'un fichier physique (ou d'un dictionnaire) l'aide des mots-cls REF et REFFLD que nous avons dj dfinis. Si, dans le fichier physique, une contrainte de validit est associe cette zone, elle sera automatiquement ramene dans le fichier d'affichage avec la description de la zone. La contrainte de validit fait alors partie intgrante du fichier daffichage. L'utilisateur ne pourra saisir l'cran une valeur sortant du domaine de validit ainsi dfini. C'est le systme qui effectue ce contrle en dchargeant totalement le programme de cette tche. Contrairement une ide reue, ces mots-cls nont aucune incidence directe sur les fichiers physiques. Ils nempchent pas un programme de placer directement dans une zone une valeur qui ne correspond pas son domaine de validit. Ils servent uniquement contrler la saisie dans les fichiers daffichage. Les mots-cls destination des fichiers d'affichage sont gnralement de niveau Zone. Ils sont rpartis en trois familles et dfinissent pour chaque zone :
38
le domaine de validit ; les caractristiques de la saisie ; la mise en forme.
Le domaine de validit
Voici les diffrents mots-cls qui dterminent un domaine de validit pour une zone : RANGE dfinit un domaine de valeurs entre deux bornes (comprises) ; VALUES prcise les valeurs admises (jusqu 100) ; COMP permet la comparaison par rapport une valeur l'aide des oprateurs suivants : EQ NE LT NL GT NG LE GE Egal Diffrent de Plus petit que Pas plus petit que Plus grand que Pas plus grand que Plus petit ou gal Plus grand ou gal ;
CHKMSGID associe un message d'erreur aux mots-cls COMP, RANGE, VALUES et CHECK. Ce message doit tre enregistr dans un fichier de messages. Si une valeur saisie est hors du domaine de validit, le systme renverra automatiquement le message spcifi.
Le contrle de la saisie
CHECK prcise les caractristiques de la saisie. Voici les principales valeurs qui peuvent tre spcifies pour ce mot-cl :
CHECK(ME) : au moins un caractre doit tre saisi pour cette zone. Ce mot-cl est associer aux zones qui doivent tre obligatoirement renseignes (la valeur de la cl, par exemple) ; CHECK(MF) : si un caractre est saisi, alors chaque position de la zone doit tre saisie. Ce mot-cl est associer aux zones qui doivent tre totalement remplies (le code postal, par exemple) ;
39
CHECK(ME MF) : combine les deux contraintes que nous venons de citer : la zone est saisie obligatoire et tous les caractres doivent tre renseigns.
REFSHIFT dfinit les caractristiques du clavier lors REFSHIFT(X) positionne le clavier de telle manire
de la saisie d'une zone. que seuls les caractres
majuscules seront saisis.
Mise en forme
Deux mots-cls d'dition permettent l'affichage ou l'impression de zones de type Dcimal condens sous un certain format. Il est classique, par exemple, d'avoir la date stocke dans une zone dcimale de longueur 6, sans positions dcimales, et de prsenter son contenu sous la forme jour/mois/anne (211196 donnant 21/11/96).
EDTCDE
permet une mise en forme classique (suppression de zros non significatifs, ajout de ponctuation...) en employant des codes d'dition prdfinis. L'OS/400 en met dix-huit notre disposition, chacun ayant un comportement diffrent selon qu'il s'applique un nombre positif ou ngatif et en fonction de la prsence ou de l'absence de positions dcimales. Nous ne dtaillerons pas tous les cas possibles, en voici seulement quelques exemples :
CODE EDTCDE(Y) EDTCDE(1) EDTCDE(1 *) EDTCDE(C) EDTCDE(K $) VALEUR DE LA ZONE AFFICHAGE
011194 12345.67 00012.34 -1234.56 -1234.56
01/11/94 12,345.67 **,*12.34 1234.56CR $1,234.56-
Au niveau de la sortie (fichier d'affichage ou fichier d'impression), il est important de prvoir une zone assez grande pour accueillir tous les caractres aprs mise en forme. Par exemple, une zone de longueur 6, avec un code d'dition Y, occupera 8 positions en sortie. Nous renvoyons la documentation de l'OS/400, Data Description Specification Reference (chapitre Display File, mot-cl EDTCDE) pour avoir un tableau complet sur les diffrentes mises en formes apportes par ce mot-cl. En marge des valeurs proposes par l'OS/400, nous pouvons dfinir cinq codes d'dition (de 5 9) grce la commande CRTEDTD.
40
Le mot-cl EDTWRD permet d'aller beaucoup plus loin dans la mise en forme, en intgrant du texte dans la zone.
Exemple
L'exemple 3.5 prsente la mise en uvre des principaux mots-cls que nous venons de voir.
NOM FMT1 NOMCLI PRODUIT DATE MONTANT CODE
FONCTION 5 15 6 8 2 0 CHECK(ME) RANGE(10000 50000) REFSHIFT(X) EDTCDE(Y) EDTCDE(K F) VALUES(AC VE RE BA) REFSHIFT(X)
0 2
Exemple 3.5 : mise en uvre des mots-cls lis aux fichiers d'affichage.La zone NOCLI est saisie obligatoire et sa valeur doit tre comprise entre 10 000 et 50 000 ; PRODUIT sera saisie en majuscules ; DATE sera prsente sous la forme xx/xx/xx ; MONTANT aura le format F123,456.78- en sortie ; CODE pourra prendre pour valeur AC, VE, RE ou BA et sera saisie en majuscules.
Remarques
Selon leur nature, les mots-cls que nous venons de voir ne seront applicables que lors de la saisie ou de laffichage (et ventuellement de limpression) d'une zone. Ils peuvent toujours tre inhibs dans un fichier d'affichage (ou d'impression) en faisant rfrence une zone dun fichier physique par le mot-cl DLTEDT.
Partage de format
L'exprience montre que l'on a parfois crer des fichiers qui ont le mme format que des fichiers existants, par exemple quand on initialise une nouvelle anne en comptabilit (le fichier qui accueillera les nouvelles critures a le mme format que le fichier de l'anne qui se termine). Pour viter un travail long et fastidieux de codification des zones du fichier, il est possible de rcuprer le format d'un fichier physique ou logique dj cr, et qui possde la mme structure, grce au mot-cl FORMAT. L'exemple 3.6 prsente une telle dfinition.
41
NOM R K FMT1 NOCLI
FONCTION UNIQUE FORMAT(BIB1/FICH1)
Exemple 3.6 : partage de format.
Le nom du format du nouveau fichier doit tre le mme que le nom du format du fichier existant. Dans l'exemple 3.6, le nom du format du fichier FICH1 de la bibliothque BIB1 doit tre FMT1. Toutes les zones (et seulement les zones) du format partag sont ramenes, avec leurs caractristiques. Les mots-cls de niveau Fichier et la cl doivent tre redfinis. En utilisant FORMAT, on ne peut dcrire aucune zone, c'est--dire que l'on ne peut ni modifier, ni rajouter, ni enlever une zone par rapport au format partag. Le partage de format n'entrane aucune dpendance entre les fichiers.
Valeur par dfaut

A la cration d'un enregistrement, si une zone n'est pas renseigne, elle prend pour valeur 0 si elle est de type Dcimal condens et des "blancs" si elle est de type Alphanumrique. Le mot-cl DFT associe une valeur par dfaut une zone (exemple 3.7).
R NOM FMT1 MOIS JOUR HEXA FONCTION FORMAT(BIB1/FICH1) DFT('01') DFT(1) DFT(X'D1D2')
2 2 2
Exemple 3.7 : dfinition de la valeur par dfaut pour une zone. La zone MOIS, de type Alphanumrique, a '01' comme valeur par dfaut, JOUR, de type Dcimal condens, a 1 et HEXA, de type Hexadcimal, 'D1D2' (reprsentation partielle des DDS).
En mise jour, cette valeur par dfaut est utilise chaque fois que la zone n'est pas renseigne, par exemple : lors de la cration d'un enregistrement travers un fichier logique qui ne possde pas cette zone dans son format ; la cration d'enregistrements grce la commande INZPFM ;
42
et lors de l'utilisation de la commande CPYF avec FMTOPT(*MAP) si cette zone n'existe pas dans le fichier d'origine. En lecture du fichier physique travers un fichier logique joint, cette valeur par dfaut peut tre renvoye au programme dans un cas particulier. Nous le traiterons dans le chapitre consacr aux fichiers logiques joints (mot-cl JDFTVAL).
En-tte de colonne
Le rsultat d'une analyse Query est une liste dont les colonnes sont, par dfaut, identifies par le nom des zones qu'elles reprsentent, ce qui n'est pas toujours parlant pour un utilisateur final. De nombreux produits et utilitaires de l'OS/400 (Query, SDA, DFU, SQL...) extraient automatiquement l'en-tte de colonne associ une zone, s'il a t codifi. Les rsultats sont alors prsents sous une forme plus comprhensible pour l'utilisateur final. Il est donc important de placer ces en-ttes au niveau du fichier physique (ou encore mieux, au niveau du dictionnaire, s'il existe). C'est le mot-cl COLHDG qui permet de codifier cette fonction (exemple 3.8). L'en-tte de colonne peut tre compos au maximum de 3 parties de 20 caractres. Chaque partie doit tre encadre par des quotes (') et spare de la suivante par un espace ; lors de la gnration dun tat, chaque partie est place sur une nouvelle ligne. Dans l'exemple 3.8, l'en-tte de la zone NOMCLI est compos de 3 parties, il est donc prsent sur trois lignes. Pour PRODUIT, l'en-tte n'est compos que d'une partie et occupe donc une seule ligne.
R NOM FMT1 NOMCLI PRODUIT TYPPRO QTE Nom du client ARNAL ARNAL ARNAL DAUDET FONCTION 15 15 3 3 COLHDG('Nom' 'du' 'client') COLHDG('Nom du produit')
Nom du produit CARTE TR CARTE ET MEMOIRE 16M CARTE TR
TYPPRO COM COM MEM COM
QTE 5 2 2 1
Exemple 3.8 : codification de l'en-tte de colonne et rsultat d'une analyse Query pour un fichier physique. Remarquer que Nom du Client est sur trois lignes, et que Nom du produit est sur une seule ligne.
43
Il ne faut pas confondre COLHDG avec TEXT. Ce dernier permet de saisir un commentaire, de 50 caractres au plus, associ une zone (ou un format) et qui ne peut tre exploit par les utilitaires de l'OS/400. Il est essentiellement destination du programmeur car il est utilis d'une part pour illustrer le source et d'autre part dans les commandes de l'OS/400 (DSPFFD, DSPFD...). Toutefois, si TEXT n'est pas codifi pour une zone, c'est le contenu de COLHDG qui sera utilis par ces commandes.
44
Le traitement des dates Introduction

Depuis sa version V2R1M1, l'OS/400 supporte de nouvelles structures de donnes pour rpondre aux exigences de l'architecture de base de donnes rparties (DRDA). Pour assurer la compatibilit avec d'autres SGBD tels que DB2 ou SQL/DS sur gros systmes , la base de donnes de l'OS/400 a d intgrer trois nouveaux types (Date, Time et Timestamp), les zones longueur variable et les zones valeur indfinie. En programmation, le traitement des dates est nettement simplifi avec les langages ILE et avec SQL qui supportent directement ces trois types.
La codification
Dans les DDS, une zone de type Date doit tre dclare avec un L en colonne TYPE (position 35). Dans le fichier, elle occupe 4 octets mais elle est renvoye au programme avec le format qui est spcifi dans le mot-cl DATFMT (par dfaut, c'est le format du travail). Le sparateur est indiqu dans le mot-cl DATSEP sauf pour quelques formats tels que *EUR, *USA ou *ISO qui ont leur propre sparateur. Voici les principaux formats : *MDY, *DMY, *YMD : o M reprsente le mois, D le jour et Y l'anne chacun occupant 2 positions ; *JUL : format de la date julienne. Lanne est codifie sur deux positions et le quantime du jour sur trois. Par exemple 94123 reprsente le 123e jour de 1994 ; *EUR : format europen (jj.mm.aaaa) ; *USA : standard USA (mm/jj/aaaa) ; *ISO : standard ISO (aaaa-mm-jj). Une zone de type Heure (Time) doit tre dclare avec un T en colonne TYPE (position 35). Dans le fichier, elle occupe trois octets mais elle est renvoye au programme avec le format qui est spcifi dans le mot-cl TIMFMT (par dfaut, c'est le format hh mn ss). Le sparateur est indiqu dans le mot-cl TIMSEP sauf pour quelques formats tels que *EUR, *USA ou *ISO qui ont leur propre sparateur.
45
Voici les principaux formats : *HMS : standard de l'OS/400 (hh mn ss) avec le sparateur spcifi dans le motcl TIMSEP ; *EUR et *ISO : format europen (hh.mn.ss) ; *USA : standard USA (hh:mn AM ou hh:mn PM). Une zone de type Horodatage (timestamp) doit tre dclare avec un Z en colonne type. Elle occupe 10 octets dans le fichier et elle est toujours renvoye sous le format (26 caractres) : aaaa-mm-jj-hh.mn.ss.uuuuuu. Le millionime de seconde peut ainsi tre gr. L'exemple 3.9 nous montre la codification d'un fichier physique utilisant ces diffrents types de donnes.
R NOM FMT1 NUMCLI DATE HEURE HOROD FONCTION 5 L T Z 0 DATSEP(-) TIMFMT(*USA)
Exemple 3.9 : codification des zones de type Date, Heure et Horodatage. Remarquer quaucune longueur ne doit tre prcise pour ces zones.
Liens avec la programmation

Le support de ces types est complet avec SQL, mais pratiquement inexistant pour les langages non-ILE tels que le RPG/400, le Cobol ou mme le langage de contrle (jusqu la version V2R3M0 de lOS/400). Avec larrive des langages de type ILE, principalement avec la version V3R1M0, il ny a plus de contraintes. En RPG/400, par dfaut, les zones de type Date, Time et Timestamp sont ignores et donc inaccessibles. Elles seront supportes si le programme a t compil avec l'option suivante :
CRTRPGPGM .....CVTOPT(*DATETIME)
Dans ce cas, ces zones seront vues comme du texte de longueur fixe, donc aucun calcul sur les dates ne pourra tre ralis simplement. De plus, ces zones ne pourront tre utilises comme cl ou pour des traitements entre limites.
46
Le RPG IV, compilateur ILE, supporte directement les zones de type Date, Heure et Horodatage. Il propose mme des codes oprations pour les grer comme lajout ou le retrait dune dure une autre dure. La commande OPNQRYF met notre disposition des fonctions intgres qui permettent les calculs sur les dates et les horaires.
Les zones de longueur variable

Dans un fichier physique, tous les enregistrements ont le mme format, donc la mme longueur. Le support des zones de longueur variable est une sorte de verrue greffe sur la base de donnes de l'OS/400. Le gain en octets n'est pas toujours significatif (une place importante est consomme pour la gestion des longueurs variables) et les temps de traitements sont augments. Cette possibilit nous semble devoir tre mise en uvre seulement pour des besoins spcifiques ou pour communiquer avec des bases de donnes autres que celle de l'OS/400. Au niveau des DDS, le mot-cl VARLEN dfinit une zone de longueur variable (exemple 3.10). Deux longueurs sont prendre en considration : la longueur maximale de la zone est celle dfinie en colonne LONGUEUR ; la place alloue dans l'enregistrement proprement dit est spcifie dans le motcl VARLEN. Si aucune valeur n'est prcise, aucune place n'est rserve. Lors de l'criture d'une zone de longueur variable, la partie de la zone alloue dans l'enregistrement (codifie avec VARLEN) est remplie en premier, les caractres qui ne rentrent pas sont crits dans une zone de dbordement. Pour chaque zone, 2 octets contiennent la longueur valide de cette zone (en binaire) et 8 octets pointent sur l'adresse de la zone de dbordement. Dautres octets sont encore utiliss par le systme pour la gestion des donnes en zone de dbordement.
R NOM FMT1 NOMCLI PRODUIT LONGUEUR 100 100 FONCTION VARLEN(15) VARLEN
Exemple 3.10 : mise en uvre du mot-cl VARLEN. La zone NOMCLI a une longueur de 15 caractres alloue dans l'enregistrement de format FMT1 et pourra comporter jusqu' 100 caractres. PRODUIT n'a pas de place rserve et pourra avoir une longueur de 100 caractres.
Les zones de ce type sont accessibles par les programmes RPG/400 qui ont t compils avec l'option suivante :
47
CRTRPGPGM .....CVTOPT(*VARCHAR) Dans ces programmes, la variable gnre occupe deux caractres de plus que la longueur maximale de la zone, les deux premiers octets contenant, en binaire, la longueur relle de la zone. Il appartient au programmeur de grer ces deux octets :
en lecture, pour connatre la partie valide de la zone ; en criture, car il faut y indiquer la longueur valide de la zone mise jour. En RPG/400, de nombreuses restrictions s'appliquent aux zones de ce type : elles ne peuvent tre utilises comme cls, ne permettent pas le traitement entre limites et ne supportent pas les indicateurs de rupture (Ln) ou de concordance (Mn). Le langage de contrle peut lire les zones de longueur variable si dans la commande DCLF le paramtre ALWVARLEN a la valeur *YES. La structure de la variable ainsi lue est la mme que celle que nous avons dcrite pour le RPG, c'est-dire deux octets en tte qui contiennent la longueur valide en binaire, suivis du nombre de caractres correspondant la plus grande longueur possible. Query, SQL, DFU et la commande OPNQRYF supportent les zones de longueur variable.
Les zones valeur indfinie

En standard, il est impossible de savoir si la valeur 0 d'une zone correspond une valeur rellement saisie ou s'il s'agit de la valeur par dfaut. Les zones autorisant les valeurs indfinies nous permettent de faire la distinction. Le mot-cl ALWNULL prcise qu'une zone peut avoir la valeur NULL, cest--dire tre indfinie. Pour chacune des zones de ce type et pour chaque enregistrement, le systme tient une table de bits prcisant si une valeur a t saisie ou non. SQL, Query et les commandes CPYF et OPNQRYF supportent ces zones. Un programme RPG/400 peut lire ces zones s'il a t cr avec l'option suivante :
CRTRPGPGM .....ALWNULL(*YES)
Si une zone a la valeur indfinie, c'est la valeur par dfaut qui est renvoye. Aucun moyen ne nous permet donc de savoir si la zone avait la valeur indfinie. Les mmes restrictions que nous avons vues pour le type Date sont applicables pour le traitement de ces zones.
48
Un programme en langage de contrle peut lire les zones de ce type si dans la commande DCLF le paramtre ALWNULL a la valeur *YES.
Environnement multinational
Dans un environnement multinational, la gestion des caractres accentus est toujours dlicate. Pour le franais, par exemple, il n'est pas rare de trouver les caractres { ou } la place des ou .
Les pages de code

Sur tout ordinateur, un caractre est cod sous la forme d'un certain nombre de bits. Sur l'AS/400, et pour les occidentaux, 1 caractre est stock sur 8 bits (1 octet). Pour certaines langues orientales (coren, japonais, chinois...), il faut 2 octets pour reprsenter chaque caractre. Ce type de codification est appel DBCS (Double-Byte Character Set). Une page de code est une table qui fait le lien entre un caractre et sa reprsentation informatique. Les problmes lis aux caractres accentus viennent du fait qu'il existe une page de code diffrente pour chaque pays (ou presque). Autrement dit, tous les caractres ne sont pas codifis de la mme manire aux tats-Unis et en France. Heureusement, les principales lettres (A...Z et a...z) et les caractres 0 9 ont une reprsentation constante. Ce qui varie d'une page de code une autre c'est essentiellement la codification des caractres accentus. Comparons les pages de code US (037) et France (297) : Valeur hexadcimale 51 54 C0 D0 C1 E9 Page de code 297
(FRANCE)
Page de code 037

(TATS-UNIS)
{ } A Z
{ } A Z
Il apparat clairement que le caractre est codifi par X'51' sur une machine qui utilise la page de code US. Ce caractre affich sur un cran franais sera traduit par {.
EBCDIC-ASCII
49
Dans un environnement de bases de donnes rparties, d'autres problmes encore plus complexes peuvent apparatre. L'AS/400 utilise une codification des caractres appele EBCDIC (Extended Binary Coded Decimal Interchange Code), d'autres systmes (les micro-ordinateurs, par exemple) emploient l'ASCII (American Standard Code for Information Interchange). On imagine aisment les soucis de lutilisateur d'un micro-ordinateur (ASCII) de langue espagnole qui dsire accder aux donnes d'un AS/400 (EBCDIC) franais.
Le CCSID
Le CCSID (Coded Character Set Identifier) est un nombre stock sur 2 octets qui indique comment est codifie une information de type Alphanumrique (ASCII ou EBCDIC, page de code...). Le CCSID peut tre associ un AS/400 (valeur systme QCCSID), un travail, un utilisateur, un fichier et mme une zone. Grce au CCSID, lOS/400 sait comment a t codifie une information et assure ventuellement les conversions ( partir de tables), afin que chacun puisse voir correctement les donnes. Le mot-cl CCSID employ au niveau Fichier dfinit la structure d'encodage utilise pour toutes les zones alphanumriques de ce fichier. Codifi au niveau Zone, il s'applique cette zone seulement.
Conclusions
Le CCSID n'est utiliser que dans un environnement multinational et ne s'applique qu' des informations de type Alphanumrique. Heureusement, la codification des zones dcimales est standardise !
Les principaux mots-cls des DDS Les DDS de niveau Fichier

ALTSEQ CCSID REF UNIQUE
dfinit une table de tri pour les zones cls ; indique quelle est la structure d'encodage des zones de type Alphanumrique pour ce fichier ; fait rfrence un dictionnaire ; signifie que deux enregistrements ne pourront avoir une mme valeur de cl.
Les enregistrements ayant une mme valeur de cl apparatront tris dans l'ordre :
50
FCFO FIFO LIFO
lenregistrement le premier modifi est renvoy dabord ; le premier crit dans le fichier est renvoy dabord (valeur par dfaut) ; le dernier crit dans le fichier est renvoy en premier.
Les DDS de niveau Format

FORMAT TEXT
duplication du format d'un fichier existant ; commentaires.
Les DDS de niveau Zone

ALIAS ALWNULL CCSID CHECK CHKMSGID COLHDG COMP DATFMT DATSEP DFT EDTCDE EDTWRD FLTPCN RANGE REFFLD REFSHIFT TEXT TIMFMT TIMSEP VALUES VARLEN
dfinit un nom de substitution pour une zone ( destination des programmes) ; autorise les valeurs inconnues (NULL) ; indique quelle est la structure d'encodage de cette zone ; prcise les caractristiques de la saisie ; identifie le message d'erreur renvoyer en cas de saisie d'une valeur hors du domaine de validit ; dfinit un en-tte de colonne (jusqu' trois parties) ; permet la comparaison avec une valeur ; dfinit le format d'une zone de type Date ; dfinit le sparateur pour une zone de type Date ; dfinit une valeur par dfaut ; dfinit un code d'dition ; dfinit un mot d'dition ; indique le niveau de prcision des zones de type virgule flottante ; dfinit un domaine de validit ; fait rfrence une zone d'un dictionnaire ou du source ; conditionne le clavier ; commentaires ; dfinit le format d'une zone de type Heure ; dfinit le sparateur pour une zone de type Heure ; donne la liste de valeurs admises ; dfinit une zone de longueur variable.
Les DDS de niveau Cl
51
Les enregistrements apparaissent tris :

ABSVAL DESCEND DIGIT NOALTSEQ SIGNED UNSIGNED ZONE
sur la valeur absolue des zones ; dans l'ordre dcroissant ; selon la partie numrique de la reprsentation hexadcimale ; sans tenir compte, pour cette zone cl, de la table de tri spcifie dans le mot-cl ALTSEQ ; en tenant compte du signe (la valeur par dfaut pour un tri classique) ; en ignorant le signe ; c'est la reprsentation hexadcimale qui est utilise pour effectuer le tri ; selon la partie alphabtique de la reprsentation hexadcimale.
La commande de cration de fichiers physiques

L'tape que nous venons de prsenter nous a permis de codifier, l'aide des DDS, un membre source contenant la description d'un fichier physique. L'tape suivante consiste crer (ou compiler) ce membre, l'aide de la commande CRTPF, pour obtenir un objet de type *FILE. Cette commande contient de nombreux paramtres ; nous allons dcrire les principaux en procdant comme pour les mots-cls des DDS, c'est--dire en les regroupant par thmes. Une liste exhaustive de ces paramtres sera prsente la fin de ce chapitre.
Dfinition du fichier
Le seul paramtre obligatoire est le nom du fichier crer (paramtre FILE). Par dfaut, le fichier est cr dans la bibliothque courante, si elle existe, sinon il est plac dans la bibliothque QGPL.
SRCMBR dfinit le membre source qui est utilis. La valeur SRCMBR(*FILE) indique que le nom de ce membre est le mme que celui du fichier crer. Par dfaut, il appartient au fichier source QDDSSRC de la bibliothque courante. Ainsi, la commande :
52
CRTPF FILE(FICH1)
cre le fichier FICH1 dans la bibliothque courante (ou dans QGPL), partir du membre FICH1 du premier fichier QDDSSRC trouv dans la liste de bibliothques. Ces paramtres peuvent videmment tre modifis comme le montre la commande suivante :
CRTPF FILE(BIB1/FICH1) SRCFILE(BIB2/SOURCEDDS) SRCMBR(PF1)
Le fichier FICH1 est cr dans la bibliothque BIB1 partir du membre source PF1 contenu dans le fichier source SOURCEDDS de la bibliothque BIB2.
Cration d'un fichier sans DDS

Les DDS permettent de dfinir la structure des enregistrements et ventuellement la cl d'un fichier. Mais, il est toujours possible de crer un fichier physique sans DDS. La structure des enregistrements est alors impose par le paramtre FILETYPE : FILETYPE(*DATA) est la valeur par dfaut. Les enregistrements contiennent une seule zone de type Alphanumrique dont la longueur est dfinie par le paramtre RCDLEN. La zone et le format possdent le mme nom que le fichier ; FILETYPE(*SRC) prcise que le fichier contient des sources. Le format est alors compos de trois zones : SRCSEQ, en Dcimal tendu de 6 dont 2, qui contient le numro de squence de l'enregistrement ; SRCDAT, en Dcimal tendu de 6 dont 0, pour la date de cration (ou de dernire modification) de cet enregistrement ; SRCDTA, de type Alphanumrique, pour les donnes source proprement dites. La longueur totale de l'enregistrement est donne par le paramtre RCDLEN. Ainsi, pour une valeur de 100, la zone SRCDTA a une longueur de 88 (100 - 6 - 6). La valeur associe RCDLEN doit donc tre suprieure ou gale 13 (6 pour SRCSEQ, 6 pour SRCDAT et au moins 1 pour SRCDTA).
Gravit des messages
53
GENLVL est un filtre qui ne laisse passer que les messages qui ont une gravit infrieure une certaine valeur et qui provoque la fin anormale de la compilation si cette gravit lui est suprieure ou gale. GENLVL(20),
valeur par dfaut, signifie que le fichier ne sera pas cr si, lors de la compilation, un message de gravit suprieure ou gale 20 est gnr.
Les messages de gravit 0 sont des messages d'information, ceux de gravit 10 des warning, cest--dire des messages d'attention (une erreur peut se cacher derrire). Au-del (20 et plus), il s'agit vraiment d'une erreur. Il est donc conseill de laisser la valeur GENLVL(20) afin d'assurer l'intgrit de la base de donnes. FLAG spcifie la gravit minimale des messages conservs dans la liste de compilation. Par dfaut la valeur est 0 c'est--dire que tous les messages sont produits dans cette liste.
Les membres
La notion de membre est fondamentale dans l'organisation de la base de donnes de l'OS/400, nous la traiterons donc en dtail la suite de cette partie consacre la commande CRTPF. Voici trois mots-cls qui ont un rapport direct avec la notion de membre : MBR dfinit le nom du membre cr en mme temps que le fichier. Aucun membre n'est ajout au fichier s'il a pour valeur MBR(*NONE). Par dfaut, MBR(*FILE) provoque la cration d'un membre qui a le mme nom que le fichier. Cette valeur fait que de nombreux utilisateurs ignorent la notion de membre. En standard, un membre est cr avec chaque fichier. Ce membre est ensuite pris par dfaut pour toutes les oprations sur les enregistrements. La notion de membre peut donc tre totalement transparente pour une utilisation de base. A sa cration, un fichier peut se voir ajouter un membre au plus. La commande ADDPFM permet, par la suite, d'ajouter de nouveaux membres un fichier physique ; MAXMBR indique le nombre maximum de membres que le fichier pourra possder ; EXPDATE prcise la date d'expiration pour tous les membres du fichier. Au-del de cette date et lors d'une tentative d'utilisation de ce fichier, un message sera envoy.
Le chemin d'accs
54
Un fichier physique peut tre dfini avec une cl. Comme nous l'avons dj signal, les enregistrements ne sont pas rellement tris dans le fichier, mais apparaissent comme tels grce un chemin d'accs, sorte d'index, qui indique l'ordre dans lequel les enregistrements doivent tre vus. Il existe un chemin d'accs par membre et, d'une manire gnrale, tout ce que nous allons dcrire par la suite s'applique au chemin d'accs de chacun des membres des fichiers physiques. Le chemin d'accs est une des composantes essentielles des fichiers logiques. Nous traiterons ce sujet en dtail dans la section Les chemins d'accs du chapitre 4. Les mmes raisonnements pourront tre tenus pour les chemins d'accs des fichiers physiques et logiques car il s'agit de structures identiques. Dans la commande de cration des fichiers physiques, trois paramtres se rapportent au chemin d'accs. Nous allons les dcrire rapidement en renvoyant au chapitre cit ci-dessus. Il s'agit de MAINT, RECOVER et FRCACCPTH.
Le paramtre MAINT
MAINT dfinit comment est maintenu un chemin d'accs. La maintenance est l'opration qui consiste mettre jour un chemin d'accs aprs la modification dun enregistrement du fichier physique (par ajout, suppression ou modification de la valeur de la cl). Cette tche peut tre lourde pour le systme si de nombreux chemins d'accs sont associs au fichier (par l'intermdiaire de fichiers logiques).
Si un programme travaille directement sur le fichier physique, chaque modification des enregistrements est immdiatement rpercute dans le chemin d'accs associ (au fichier physique). Si, au contraire, les enregistrements sont modifis travers un fichier logique, la maintenance du chemin se fera en fonction de la valeur donne au paramtre MAINT de la commande CRTPF. Voici les diffrentes valeurs possibles : MAINT(*IMMED) indique que la maintenance est immdiate. Cette valeur est obligatoire si le mot-cl UNIQUE est spcifi dans les DDS du fichier physique. Il faut, en effet, que le systme vrifie dans le chemin d'accs s'il n'existe pas dj un enregistrement ayant mme valeur de cl. C'est la valeur par dfaut. Elle est souhaitable pour les fichiers physiques (avec une cl) utiliss en interactif. Cette option est la plus coteuse en termes de ressources systme mais garantit un temps d'ouverture minimal des fichiers ; MAINT(*REBLD) provoque la reconstruction du chemin d'accs lors de l'ouverture du fichier physique. Tant que le fichier est ouvert, la maintenance est immdiate. Une fois le fichier ferm, plus aucune maintenance n'est assure.
55
Le temps d'ouverture est long (surtout si le fichier est gros), mais les ressources systme consommes sont faibles. Cette valeur est choisir pour les fichiers actifs (avec de nombreuses modifications) traits en batch ; MAINT(*DLY) diffre la maintenance l'ouverture du fichier. Tant que le fichier est ferm, les modifications qui doivent affecter son chemin d'accs sont stockes, la maintenance s'effectuant lors de l'ouverture du fichier. Si les modifications sont trop nombreuses (suprieures 10 ou 25% selon les documentations IBM), le systme arrte leur stockage et le chemin est totalement reconstruit la prochaine ouverture (comparable la valeur *REBLD). Sinon, il est seulement mis jour, louverture, l'aide des informations conserves. Cette valeur est utiliser pour des fichiers traits en batch, car le temps d'ouverture peut tre long, mais subissant peu de modifications. MAINT n'est utilisable que si une cl a t dfinie dans les DDS du fichier physique (sinon il n'y a pas de chemin d'accs !).
Le paramtre FRCACCPTH
La maintenance du chemin d'accs est effectue en mmoire principale et, par dfaut, n'est rellement envoye sur le disque que plus tard, soit un moment choisi par le systme, soit la fermeture du fichier, soit, enfin, aprs un ordre spcifique tel que FEOD en RPG (fermeture et ouverture logique dun fichier). Si un incident majeur (panne dalimentation ou dfaillance dun composant) se produit entre la modification du chemin en mmoire principale et son criture sur le disque, la mise jour est perdue. Le fichier et son chemin d'accs ne sont plus en concordance (voir alors le paramtre RECOVER). Cet incident est heureusement rarissime.
FRCACCPTH(*YES)
force l'criture immdiate sur disque de toute modification du chemin d'accs, ce qui diminue le risque d'erreur que nous venons de citer. Cette valeur peut provoquer une augmentation sensible des temps de rponse pour ce fichier et peut mme dgrader les performances gnrales du systme si de nombreuses mises jour sont effectues de cette manire. La valeur par dfaut est FRCACCPTH(*NO) afin de prserver des temps de rponse optimaux. Il existe un processus comparable pour les enregistrements conditionns par le paramtre FRCRATIO.
Le paramtre RECOVER
56
Lors d'un incident (une coupure d'lectricit, par exemple), il est possible que le chemin d'accs et le fichier physique correspondant ne soient plus en concordance. Si aucune prcaution n'a t prise (par la journalisation (avec SMAPP) ou par l'criture force sur disque), le systme devra reconstruire le chemin d'accs. Le paramtre RECOVER indique quand cette reconstruction doit avoir lieu : RECOVER(*NO) : le chemin d'accs est reconstruit la premire ouverture du fichier qui de ce fait est longue ; RECOVER(*IPL) : le chemin d'accs est reconstruit pendant l'IPL. Cette option alourdit la phase d'initialisation du systme, souvent dj longue aprs un arrt anormal. L'intrt rside dans le fait que, ds que l'cran d'ouverture apparat, les fichiers sont disponibles. RECOVER(*AFTIPL) : le chemin est reconstruit aprs l'IPL, qui sera plus court, mais les programmes ne peuvent accder un fichier tant que la construction de son chemin d'accs n'est pas termine. La commande EDTRBDAP permet de grer la reconstruction des chemins d'accs aprs l'IPL.
Ecriture force en mmoire secondaire

indique le nombre d'enregistrements qui seront traits avant d'tre rellement crits sur disques. Par le mme mcanisme que celui que nous avons dtaill pour le mot-cl FRCACCPTH, une opration sur un enregistrement (insertion, suppression, modification) n'est pas rpercute immdiatement en mmoire secondaire, mais est conserve en mmoire principale. Tout cela est totalement transparent pour les programmes (et donc pour les utilisateurs), une opration tant considre comme effectue ds qu'elle est ralise en mmoire principale. Cette mmoire est volatile. Si un incident majeur survient, tel qu'une coupure d'lectricit, son contenu disparait. On peut se retrouver alors dans la situation critique o le programme (et donc l'utilisateur) a modifi l'enregistrement et o cette modification qui n'a pas t enregistre sur disque est perdue.
FRCRATIO
A l'IPL suivant cet arrt, la base de donnes peut tre dans un tat incohrent, certains fichiers n'tant plus jour. Il est donc essentiel d'analyser leur contenu avant de relancer les applications. La journalisation des fichiers physiques est un des moyens qui permet d'viter ces soucis. Le paramtre FRCRATIO de la commande CRTPF en est un autre, moins puissant mais plus simple mettre en uvre. Il peut avoir deux valeurs :
57
FRCRATIO(*NONE) : c'est le systme qui dtermine quand il faut crire les enregistrements sur disque ; FRCRATIO(NOMBRE) : force l'criture sur disque lorsque NOMBRE enregistrements ont t traits. L'impact sur les performances pouvant tre sensible, cette valeur n'est utiliser que pour des besoins spcifiques.
Les fichiers physiques et la mmoire secondaire

Dans cette partie, nous allons voir comment est allou l'espace disque un fichier physique, puis nous estimerons sa taille en fonction du nombre d'enregistrements prsum pour chacun de ses membres.
La taille
Contrairement ce qui se pratique avec d'autres systmes, la taille d'un fichier n'est pas dfinie lors de sa cration, aucune place ne lui est rserve, et, en principe, il s'accrot sur disque automatiquement au fur et mesure des besoins. La prsence du paramtre SIZE (taille en anglais) semble en contradiction avec ce principe. En fait, il s'agit d'un garde-fou qui permet de contrler la croissance d'un fichier. On imagine les problmes qui peuvent rsulter de l'accroissement d'un fichier sous l'effet d'un programme qui boucle en ajoutant systmatiquement un enregistrement, pour peu qu'il soit lanc la veille d'un week-end. Sans surveillance, ce fichier pourra occuper tout l'espace disque disponible provoquant un incident regrettable (arrt anormal du systme). nous permet de contrler la croissance d'un fichier l'aide de trois valeurs. La premire (10 000 par dfaut) donne le nombre d'enregistrements qui peuvent tre placs dans un membre d'un fichier. Une fois ce nombre atteint, un message est renvoy l'historique du systme (visualisable par DSPLOG). La deuxime valeur (l'incrment) correspond au nombre d'enregistrements qui pourront ensuite tre ajouts. Il est de 1 000 en standard. Cet envoi de message et cette incrmentation s'effectuent autant de fois qu'il est indiqu dans la troisime valeur (3 par dfaut). Ensuite, un message d'interrogation est envoy l'oprateur systme (dans la file d'attente de messages QSYSOPR) lui demandant s'il faut ajouter un incrment ou arrter le travail.
SIZE
Ainsi, dans notre exemple du programme qui boucle, et si le fichier a t cr avec les valeurs par dfaut, l'ajout d'enregistrements sarrterait 13 000 (10 000 + (3 1 000)) en attente d'une rponse de l'oprateur systme. Les risques de dgat sont donc vraiment limits.
58
La valeur SIZE(*NOMAX) permet de lever ce contrle, le nombre d'enregistrements que l'on peut placer dans un membre d'un fichier dpendant des limites de l'OS/400 ( ce jour plus de 2 milliards, concurrence de quelques 266 giga-octets) ou des limites des disques de votre systme.
L'allocation
Nous avons dj signal qu'aucune place nest rserve pour les enregistrements la cration d'un fichier. Cest une premire approche thorique qui montre qu'un fichier n'est pas une bote rigide, dont la taille est dfinie lors de sa cration, mais plutt un sac qui se gonfle au fur et mesure des besoins. Dans la pratique, le paramtre ALLOCATE dfinit la place initiale alloue pour les donnes la cration de chaque membre. Il peut avoir deux valeurs : ALLOCATE(*NO) est la valeur par dfaut. Elle prcise que c'est au systme de dterminer automatiquement la place alloue aux donnes la cration de chaque membre. Cet espace, quelques kilo-octets contigus, sera occup par les premiers enregistrements placs dans le membre. Les suivants seront stocks ailleurs en mmoire secondaire, peut-tre sur un autre disque, en fonction de la place disponible. Juste aprs la cration d'un membre on peut visualiser l'espace rserv pour les premires donnes par la commande DSPFD ; ALLOCATE(*YES) indique que la place dfinie dans la premire valeur du paramtre SIZE est alloue pour chaque membre ( condition que cette valeur soit diffrente de *NOMAX) et si possible de manire contigu. La place n'est pas rserve pour les incrments, ni la cration, ni lors de l'extension.
CONTIG(*YES) provoque l'envoi d'un message la file d'attente du travail si l'allocation initiale ne peut pas s'effectuer de manire contigu.
Enfin, le paramtre UNIT dfinit l'unit sur laquelle doit tre stock le fichier. UNIT(*ANY) est la valeur par dfaut. Elle indique que les enregistrements du fichier peuvent tre placs sur n'importe quelle unit, autrement dit sur n'importe quel disque (par blocs de 512 octets). Ceci explique que la destruction d'un disque entrane la perte de toutes les donnes qui figurent sur l'ensemble des disques de l'ASP. Chaque fichier ( limage de tous les objets de lOS/400), pour peu quil soit assez gros, a des donnes dissmines sur chacun des disques de lASP. La perte dun disque brise les liens quil y a entre toutes ces donnes ; il est alors impossible de reconstituer la plupart des objets de lOS/400.
59
UNIT(NUMERO),
ou NUMERO est l'identifiant d'une unit, spcifie l'unit sur laquelle doit tre place la totalit du fichier (espace initial de chaque membre, extensions ventuelles et mme chemins daccs associs). La commande STRSST permet de connatre l'identifiant attribu par le systme chacune de ses units. Sil ny a pas assez de place, le systme allouera lespace ncessaire sur une autre unit, en envoyant un message lhistorique du systme.
Mise en garde
D'une manire gnrale, on laissera les valeurs par dfaut pour les paramtres SIZE, ALLOCATE et UNIT. On ne les modifiera que pour des besoins spcifiques et en toute connaissance de cause.
SIZE
est un garde-fou que l'on doit ajuster en fonction du nombre d'enregistrements prvus pour chaque membre. La valeur *NOMAX est dconseiller car elle inhibe toute protection.
L'allocation de l'espace total rserv aux donnes lors de la cration de chaque membre par ALLOCATE(*YES) consomme souvent une place inutile si la valeur saisie en regard de SIZE est importante. Cette place peut faire cruellement dfaut au systme et entraner une dgradation des performances. Elle n'est conseiller que dans des cas limits, par exemple, pour diminuer les temps daccs un fichier lu squentiellement. Enfin, il n'y a nos yeux pas (ou peu) d'intrt choisir l'unit sur laquelle sera plac le fichier. Si l'on dsire absolument stocker un fichier sur un disque (parce quil est plus fiable par exemple) on prfrera mettre en uvre un ASP utilisateur qui permet, de manire sre, d'isoler un fichier sur une unit (ou sur un groupe d'units).
Estimation de la taille d'un fichier physique

En faisant abstraction des remarques mises propos du paramtre ALLOCATE, nous pouvons estimer la taille d'un fichier physique l'aide de la formule suivante :
TAILLE
= (nombre d'enregistrements valides et dtruits + 1) (longueur de l'enregistrement + 1) + (5120 nombre de membres) + 1024
60
Il faut ajouter cela l'espace occup par le chemin d'accs (s'il existe), pour chacun des membres, estim par la formule suivante :
TAILLE DU CHEMIN D'ACCES =
(nombre d'enregistrements valides (longueur de la cl + 8) 0,8 1,85) + 4096
0,8 est un cfficient qui correspond une compression moyenne. 1,85 est le facteur qui permet de prendre en compte la place rserve par le systme pour l'extension du chemin d'accs. Par exemple : un fichier avec un seul membre contenant 800 enregistrements valides (d'une longueur 100) et 200 dtruits aura une taille estime de 107 245 octets soit un peu plus de 100 Ko car :
TAILLE =
(800 + 200 + 1) (100 + 1) +5120 + 1024
si ce fichier doit tre vu tri sur une zone cl de longueur 10, sa taille est augmente de 25 408 octets car :
(800 (10 + 8) 0,8 1,85) + 4096
il occupera donc 125 Ko. La commande DSPFD permet de visualiser la place rellement occupe par un fichier. Pour tre prcis, il faut rajouter que le systme maintient des structures qui occupent aussi un certain espace disque. Nous ne les dtaillerons pas car leur taille peut tre considre comme ngligeable.
Les verrouillages
Dans un environnement multi-utilisateur, le systme doit protger les enregistrements qui sont en cours de traitement contre les oprations que pourraient effectuer dautres utilisateurs. Par exemple, il pose un verrou lorsquun programme lit un enregistrement dun fichier ouvert en modification (U spcifi en colonne 15 de la spcification F de description de fichier, dans un programme RPG/400). Ce verrou est tel que les autres travaux pourront seulement consulter cet enregistrement. Que se passe-t-il, alors, si un programme essaye daccder cet enregistrement pour le modifier ?
61
Le paramtre WAITRCD de la commande CRTPF dfinit le temps, en secondes, pendant lequel le systme attendra que cet enregistrement soit libr. Au-del, un message derreur est renvoy au programme. Par dfaut, WAITRCD a la valeur 60, cest--dire que le programme pourra attendre jusqu 60 secondes avant que lenregistrement auquel il souhaite accder se libre. Ce dlai coul, il recevra un message derreur. Le paramtre WAITFILE dfinit, toujours en secondes, le temps pendant lequel un programme pourra attendre la libration du fichier concern. Au-del, un message derreur lui sera renvoy (CPF4128, par exemple). Par dfaut, la valeur est 0. Une erreur sera immdiatement renvoye au programme qui dsire accder un fichier dj verrouill. Il est important de prvoir des traitements pour rpondre aux erreurs lies lindisponibilit des fichiers ou des enregistrements. Le plus simple consiste afficher un cran (ou une fentre) prcisant lutilisateur que la ressource est indisponible et lui demandant sil dsire recommencer lopration.
Le partage du bloc de contrle (ODP) Dfinition

Le bloc de contrle (ou ODP pour Open Data Path) est une structure qui sert dintermdiaire entre le programme et un fichier. Schmatiquement, il contient : des informations gnrales sur le fichier ouvert ; le buffer denregistrement (lenregistrement courant et quelques enregistrements contigus) ; des informations de contrle telles que la position du curseur, qui indique quel est lenregistrement en cours de traitement. Par la suite, et pour simplifier, nous reprsenterons lODP avec lenregistrement courant et le pointeur qui dfinit sa position relative. Les ODP sont placs dans une structure plus importante, le PAG (pour Process Access Group), qui est en mmoire principale et qui contient toute la partie vivante du travail, c'est--dire, entre autres, les variables, la LDA (Local Data Area), et les indicateurs externes. Par dfaut, et chaque lancement de programme, un ODP est cr pour chacun des fichiers dclars dans ce programme. La place quil occupe est variable. Pour un
62
fichier daffichage, par exemple, un sous-fichier statique est totalement contenu dans lODP. La taille de ce dernier peut donc tre importante. La cration de ces blocs de contrle est consommatrice de ressources. Tout dabord de mmoire principale : laccroissement du nombre dODP (autrement dit du nombre de fichiers ouverts, pour un travail, un moment donn), entrane laugmentation de la taille du PAG. Or, toute occupation exagre de la mmoire principale a une incidence notable sur les performances. Ensuite, en ressources systme : pour crer un ODP, il faut aller chercher sur disque la description du fichier et ventuellement lire les premiers enregistrements (si le fichier est ouvert en lecture ou en mise jour). Cette dernire tche seffectue de manire asynchrone : ces enregistrements sont placs dans lODP avant mme le premier ordre de lecture du programme, ils seront immdiatement disponibles au premier READ. Pour optimiser les performances, il faut donc diminuer le nombre et la taille des ODP. Il semble difficile de jouer sur la taille. On peut, toutefois, limiter lutilisation de sous-fichiers statiques, surtout sils contiennent de nombreux enregistrements, et prfrer les sous-fichiers dynamiques. En revanche, et dans certains cas, le nombre des blocs de contrle peut tre diminu grce au paramtre SHARE de la commande CRTPF (ou des commandes associes telles que CHGPF et OVRDBF).
63
Mise en uvre
La valeur *YES pour le paramtre SHARE, permet plusieurs programmes dun mme travail de partager le mme ODP. Il faut pour cela quils accdent au mme fichier. Les figures 3.3 et 3.4 montrent lorganisation des blocs de contrle en mmoire principale, sans et avec partage de lODP.
CALL PGMA CALL PGMB CALL PGMC
1
FARINE
3 10
BEURRE 10
1
FARINE
ODP PGMA
DCLF FICH1 ... RCVF CALL PGMB RCVF ...
ODP
10 ODP
PAG
SHARE (*NO)
FARINE OEUF BEURRE LAIT SUCRE CREME
PGMB
FFICH1 READ READ READ CALL PGMC ...
10 24 10 5 12 5
PGMC
DCLF FICH1 RCVF ...
FICH1
Figure 3.3 : organisation des ODP en mmoire principale sans partage de lODP aprs lexcution de la commande RCVF du programme PGMC (matrialis par la flche).
Sans partage, on remarque que chaque programme a sa propre structure daccs aux fichiers et traite donc les enregistrements indpendamment des autres programmes. Le programme PGMA lit le premier enregistrement, PGMB en est au troisime et PGMC traite aussi le premier. Dans le cas de la figure 3.4, les trois programmes partagent le mme ODP pour le fichier FICH1 ; ils utilisent la mme structure pour accder ce fichier. Il existe donc un seul pointeur denregistrement pour ces trois programmes. Quand PGMC est appel, il est sur LAIT, dernier enregistrement trait par PGMB.
64
CALL PGMA CALL PGMB CALL PGMC
PGMA
DCLF FICH1 ... RCVF CALL PGMB RCVF ...
5
SUCRE
12
ODP
PAG
PGMB
FFICH1 READ READ READ CALL PGMC ...
SHARE (*YES)
FARINE OEUF BEURRE LAIT SUCRE CREME
PGMC
DCLF FICH1 RCVF ...
10 24 10 5 12 5
FICH1
Figure 3.4 : organisation des ODP en mmoire principale avec partage de lODP aprs lexcution de la commande RCVF du programme PGMC (matrialis par la flche).
Lors du partage du bloc de contrle, un programme appel hrite de lODP du programme appelant. Si ce dernier est positionn sur le dixime enregistrement, le programme appel se trouvera aussi sur ce dixime enregistrement. Toute modification de lODP par le programme appel (lecture denregistrement, par exemple) est rpercute au programme appelant. Il est essentiel davoir ces notions en mmoire lors de la conception dapplications mettant en uvre le partage de lODP. Dtaillons le contenu schmatique de lenregistrement courant de lODP lors des diffrentes tapes de la figure 3.4.
65
INSTRUCTION POSITION CALL PGMA RCVF CALL PGMB READ READ READ CALL PGMC RCVF RCVF 0 1 1 2 3 4 4 5 6
ODP ARTICLE QUANTITE
FARINE FARINE UF BEURRE LAIT LAIT SUCRE CREME
10 10 24 10 5 5 12 5
Enfin, il est important de noter que le type douverture du fichier, pour le programme qui va crer lODP, conditionne lutilisation du fichier pour les programmes partageant cet ODP. Si le premier programme ouvre le fichier en lecture, le partage ne pourra seffectuer quavec des programmes qui utilisent ce fichier en lecture. Sinon, un autre ODP est cr. Il reste noter que tout ceci est transparent pour lutilisateur final (au temps de rponse prs).
Conclusions
Le partage de lODP est un excellent moyen pour minimiser les temps de rponse de certaines applications. Il est couramment admis quun programme qui utilise un fichier est initialis 10 fois plus vite sil utilise un ODP dj existant pour ce fichier. Mais, les notions que nous venons de voir doivent tre totalement matrises pour viter toute erreur lors du traitement des enregistrements. La valeur par dfaut du paramtre SHARE fait quil ny a pas, en standard, de partage de lODP. Gnralement, la valeur SHARE(*NO) est laisse lors de la cration dun fichier. Le fichier peut, en effet, tre parfois utilis avec partage, pour certaines applications, et parfois sans partage pour dautres. Cest donc au moment o lon dsire utiliser le partage quil faut modifier le paramtre SHARE laide de la commande OVRDBF. Grce cette commande, le partage sera possible pour les programmes du travail en cours seulement. Enfin, il faut rappeler que, en RPG, la mise en fonction de lindicateur LR (ou lordre STOPRUN en Cobol) libre la place occupe par ce programme en mmoire principale. LODP, notamment, est alors dtruit. Les ordres RETRN en RPG, ou EXIT en Cobol, provoquent larrt du programme mais laissent lODP en mmoire principale. La prochaine ouverture sera plus rapide. Les gains peuvent tre
66
significatifs lorsquun programme est appel dans une boucle. Mais, attention, il existe quelques contraintes car les anciennes valeurs des structures contenues dans lODP (variables, sous-fichier...) sont reprises louverture. Il est donc important dinitialiser ce qui doit ltre (sous-fichier, pointeur denregistrement...).
Les groupes dactivation et lODP

Depuis la version V2R3M0 de lOS/400, le partage de lODP peut tre limit une partie des applications dun travail, une autre partie partageant ventuellement un autre ODP pour le mme fichier. Cela nest possible quavec des programmes rsultant de langages ILE qui autorisent la cration de plusieurs groupes dactivation pour un mme travail. Un groupe dactivation est une structure en mmoire principale qui contient lenvironnement dexcution dun groupe de programmes. Dans cet environnement, on trouve notamment les ODP. Lappartenance dun programme un (ou des) groupe(s) dactivation est dfinie lors de la cration des modules qui vont composer ce programme, par le paramtre ACTGRP. Lors de lexcution de ce module, ou plus exactement de lune des procdures composant ce module, le groupe dactivation est automatiquement cr sil nexiste pas. Les groupes dactivation permettent un cloisonnement entre les applications qui se droulent dans un mme travail. Chacune peut sexcuter dans son propre environnement, en tant sre quaucune autre ne viendra perturber cet environnement. La figure 3.5 montre, pour un mme travail, deux groupes de programmes qui accdent au mme fichier travers des ODP diffrents.
PGM1 PGM2 PGM3
ODP
GROUPE DACTIVATION 1
COMPTA1 COMPTA2 COMPTA3
ODP
GROUPE DACTIVATION 2
Figure 3.5 : partage dODP dans des groupes dactivation.
Les enregistrements dtruits
67
Nous avons dj signal la section Les enregistrements du chapitre 2 que les enregistrements dtruits taient seulement marqus leffacement : leurs emplacements sont conservs dans le fichier. Il est donc important de grer ces trous laisss dans les fichiers. Le paramtre DLTPCT permet de grer le nombre denregistrements dtruits. Si, la fermeture du fichier, le nombre denregistrements dtruits sur le nombre total denregistrements est suprieur la valeur indique pour ce paramtre, un message est plac dans lhistorique du systme. Par dfaut la valeur est DLTPCT(*NONE), il ny a pas de vrification, afin de minimiser les temps de fermeture des fichiers. Le paramtre REUSEDLT indique si la place occupe par les enregistrements dtruits peut tre rcupre pour placer les nouveaux enregistrements (depuis la version 2 de lOS/400). La valeur par dfaut est REUSEDLT(*NONE) : il ny a pas de rutilisation. Avec la valeur REUSEDLT(*YES), le systme maintient, pour ce fichier, une table qui indique les emplacements libres. Quelques contraintes sont lies lutilisation de cette valeur : les fichiers ne peuvent avoir une cl de type LIFO ou FIFO ; lordre des enregistrements dans le membre nest plus lordre dinsertion. On ne peut donc se fier la position relative dun enregistrement ; certaines oprations lies la journalisation peuvent tre impossibles ; il nest pas garanti dobtenir 100 % de rutilisation ; lutilisation de ces fichiers comme file dattente est proscrire, notamment parce que la lecture avec un dlai dattente (end of delay) nest pas possible. Rappelons que la commande RGZPFM permet de rorganiser un fichier, et donc dliminer les trous.
Lidentificateur de format
Lidentificateur de format est une valeur qui caractrise de manire unique un format. Il est utilis par le systme pour vrifier si un programme, et les fichiers quil utilise, sont bien au mme niveau. Autrement dit, si les formats des fichiers rellement ouverts sont identiques aux formats quavaient ces mmes fichiers lors de la compilation du programme. Ce mcanisme permet de sassurer que le programme pourra traiter correctement les donnes provenant des fichiers. Si le programme et les fichiers ne sont pas au mme niveau, le message derreur
68
CPF4131 Erreur de niveau... est renvoy lutilisateur. Il faut alors recompiler le programme. Le contrle de lidentificateur de format peut tre inhib pour un fichier, si, lors de sa cration, le paramtre LVLCHK de la commande CRTPF a pour valeur LVLCHK(*NO). Ce paramtre est aussi prsent dans les commandes CHGPF et OVRDBF. La valeur LVLCHK(*NO) est rserver des oprations ponctuelles en phase de dveloppement, jamais en production car, en cas de modification du format dun fichier, aucun gardefou nassurerait que le programme traite correctement les enregistrements. Il faut tenir compte de cet identificateur de format chaque fois que lon est amen changer les caractristiques dun fichier, notamment : en cas de modification du format. Se reporter la section Les fichiers Lidentificateur de format du chapitre 2 pour connatre les oprations qui ne modifient pas lidentificateur de format ; en cas de substitution de fichier par la commande OVRDBF. Le fichier substitu doit avoir le mme identificateur de format que le fichier qui le remplace. Il en est de mme pour les fichiers daffichage (OVRDSPF) et pour les fichiers dimpression (OVRPRTF). et lors de lutilisation de la commande OPNQRYF.
Les oprations permises

Le paramtre ALWDLT prcise si les enregistrements de ce fichier pourront tre dtruits. Si la valeur ALWDLT(*NO) est prcise, la destruction des enregistrements sera impossible. De manire identique, ALWUPD contrle la mise jour des enregistrements. Pour ces deux paramtres, la valeur par dfaut est *YES.
AUT dfinit
les droits publics pour ce fichier, comme pour tout objet de lOS/400.
Les donnes de chaque membre peuvent tre traites jusqu la date indique en regard du paramtre EXPDATE. Au-del de cette date, un message est renvoy
69
loprateur systme pour toute tentative douverture de ce membre, lui demandant si le travail peut continuer ou sil doit tre arrt. Chaque membre dun fichier peut avoir sa propre date dexpiration. La commande de substitution OVRDBF permet dinhiber cette vrification de date, grce au paramtre EXPCHK.
Le tri
La squence de tri pour les zones de type Alphanumrique qui composent la cl peut tre adapte aux besoins de chacun. C'est--dire que lon peut dfinir lordre des caractres dans le tri. A et a doivent-ils avoir le mme poids devant le tri, sinon lequel doit tre le premier ? O doit-on placer les caractres tels que , , ? Les tables de conversion (objets de type *TBL), dj traites aux niveau des motscls ALTSEQ et NOALTSEQ des DDS, permettent de redfinir la valeur devant le tri de chacun des caractres. Les tables de squence de tri, qui sont aussi des objets de type *TBL, permettent un meilleur support des langues nationales. Le systme nous propose pour chaque page de code, c'est--dire pour pratiquement chaque langue, des tables de squence de tri de deux types : poids unique : chaque caractre un poids diffrent devant le tri. Pour la table franaise, par exemple, A a la valeur 0760 et a 0750 ; poids partag : tous les caractres de la mme catgorie ont la mme valeur devant le tri. Pour la table franaise, par exemple, tous les caractres de la famille des A (A, a, , , ...) ont le poids 0690 devant le tri. Le paramtre SRTSEQ permet de dfinir la table de squence de tri rattache un fichier. La valeur par dfaut SRTSEQ(*SRC) fait rfrence la table dfinie au niveau du mot-cl ALTSEQ. SRTSEQ(*LANGIDSHR) slectionne la table poids partag correspondant la langue cite au niveau du paramtre LANGID (par dfaut, celle du travail). Enfin, SRTSEQ(*LANGIDUNQ) dfinit la table poids unique pour la langue associe LANGID. Les tables de squence de tri sont situes dans QSYS. Leur nom commence par Q, puis trois positions dfinissent le jeu de caractres, ensuite quatre valeurs numriques prcisent le CCSID et enfin une dernire lettre indique si la table est poids partag (S) ou poids unique (U). Ainsi, pour la France, les tables sont QLA10129U et QLA10129S (LA1 pour le jeu de caractre latin et 0129 pour le CCSID 297).
70
La table dfinie par le paramtre SRTSEQ est recopie dans la partie descriptive du fichier. La commande DSPFD permet de le vrifier. Cette fonction est attrayante mais dangereuse car elle peut impliquer la recration de chemins daccs temporaires. En effet, le paramtre SRTSEQ existe aussi pour le travail et mme pour le profil utilisateur. Un travail utilisant une table de squence de tri et qui accde un fichier ayant une autre table force le systme crer un chemin daccs temporaire qui correspond lordre dfinit pour le travail. La dgradation de performance peut tre notable si le fichier contient de nombreux enregistrements. Si cette fonction doit tre mise en place, il semble souhaitable que toutes les entits du systme (profil utilisateur, valeur systme, travail, fichiers physiques et fichiers logiques) aient la mme table de squence de tri.
Conclusions
La commande CRTPF que nous venons de dcrire est le mode naturel de cration dun fichier physique. Elle peut tre lance partir de PDM, par loption 14. Par dfaut, cette commande, comme toute commande de cration lance partir de PDM, est alors soumise en batch, ce qui permet de ne pas surcharger inutilement le systme. La plupart des paramtres que nous avons cits peuvent tre modifis, alors que le fichier est cr, par la commande CHGPF. La modification est alors durable. La commande OVRDBF permet de substituer la valeur de certains paramtres pour le travail en cours seulement.
Les principaux paramtres de la commande CRTPF

Voici la liste des principaux mots-cls des commandes CRTPF et CHGPF, rangs par ordre alphabtique :
ALLOCATE
ALWDLT ALWUPD AUT CCSID CONTIG DLTPCT
indique si lespace disque ncessaire pour tous les enregistrements dfinis dans le paramtre SIZE est rserv la cration du membre ; indique si les enregistrements pourront tre dtruits ; indique si les enregistrements pourront tre mis jour ; dfinit les droits publics ; prcise la structure dencodage ; prcise si le systme doit essayer dallouer lespace attribu initialement de manire contigu ; indique le pourcentage entre le nombre denregistrements dtruits et le nombre total denregistrements partir duquel
71
EXPDATE FILE FILETYPE FLAG FRCACCPTH FRCRATIO GENLVL LVLCHK MAINT MAXMBR MBR OPTION RCDLEN RECOVER REUSEDLT SHARE SIZE SRCFILE SRCMBR SYSTEM TEXT UNIT WAITFILE WAITRCD
un message est envoy lhistorique du systme ; donne la date dexpiration des enregistrements ; indique le nom du fichier crer ; spcifie si le fichier cr est destin contenir des donnes ou des sources ; indique le niveau de gravit minimal des messages pour quils soient placs dans le listing de compilation ; prcise quand le chemin daccs est rellement crit sur disque ; indique quand le systme doit crire rellement les enregistrements sur disque ; indique le niveau de gravit partir duquel le fichier ne sera pas cr ; prcise si lidentificateur de format doit tre compar celui du programme ; indique, si le fichier a une cl, comment est maintenu le chemin daccs ; prcise le nombre maximal de membres que pourra contenir le fichier ; donne le nom du membre ajout lors de la cration du fichier physique ; prcise le type dtat qui est gnr lors de la compilation ; est la longueur de lenregistrement si le fichier est cr sans DDS ; prcise le mode de reconstruction du chemin daccs aprs incident ; indique si le systme doit grer les emplacements marqus leffacement afin dy insrer les nouveaux enregistrements ; dfinit sil peut y avoir partage de lODP ; donne le nombre maximal denregistrements dans un membre ; indique le nom du fichier source ; indique le nom du membre source ; spcifie le nom du systme sur lequel est cr le fichier ; correspond au commentaire ; indique lunit sur laquelle le systme doit tenter de placer le fichier et ses chemins daccs ; prcise le dlai, en secondes, pendant lequel un programme pourra attendre que le fichier soit libr ; prcise le dlai, en secondes, pendant lequel un programme pourra attendre quun enregistrement soit libr.
72
Les membres
Les membres constituent lun des composants essentiels de DB2/400. Leur utilisation est toutefois mconnue car lOS/400, avec ses options par dfaut, peut masquer leur existence.
73
Gnralits
Dans les fichiers physiques, les donnes sont regroupes en ensembles appels membres. Par dfaut, un membre est cr avec chaque fichier. Ils possdent tous deux le mme nom, et toutes les donnes de ce fichier sont places dans ce membre. Au cours du temps, il est parfois souhaitable disoler certaines donnes (nouvelle anne en comptabilit, nouveau stock...). Il est alors possible de crer un nouveau fichier (avec un seul membre) et de placer les nouvelles donnes dedans. Il est alors ncessaire deffectuer certaines oprations qui assurent que le nouveau fichier sera trait comme le prcdent ; selon les environnements, il faudra, pour ce fichier : crer les fichiers logiques, donc copie des DDS existantes, puis modification et compilation ; mettre en uvre la journalisation ; dfinir les droits dutilisation ; revoir les sauvegardes (donc, ventuellement modifier les sources des programmes de sauvegarde) ; et parfois mme, modifier les programmes de traitement des donnes. Cette liste, non exhaustive, montre quil nest pas toujours trs simple dintgrer un nouveau fichier dans les applicatifs. Une autre possibilit consiste ajouter un membre au fichier existant. Une ligne de commande suffit gnralement pour cette opration. En revanche, pour pouvoir accder ce membre, il faut modifier, ou crer, le programme en langage de contrle qui appelle le(s) programme(s) de traitement des donnes. Mme si lutilisation de fichier multimembre na pas t dfinie lors de lanalyse (et donc implmente dans les programmes), lajout dun membre est une opration relativement simple. Il faut remarquer quune (petite !) conomie de place est ralise si lon utilise un fichier multimembre plutt que plusieurs fichiers : une seule partie descriptive de lobjet et du format est alors prsente sur disque (figure 3.6).
Les chemins daccs

Les caractristiques du chemin daccs (en fait la dfinition de la cl pour un fichier physique) sont dfinies au niveau du fichier. Mais le fichier lui-mme na
74
pas de chemin daccs ; ces structures sont en fait associes chaque membre. Il ny a donc pas de diffrence, ce niveau, entre un fichier multimembre et plusieurs fichiers monomembre.
Fichier STOCK
DESCRIPTION
Fichier PARIS
Fichier MONTPELLIE
Fichier LYON
PARIS
PARIS
MONTPELLIE
LYON
MONTPELLIE
MEMBRES
LYON
MULTIMEMBRE
MULTIFICHIER
Figure 3.6 : comparaison des solutions fichier multimembre et multifichier.
Remarques
Lutilisation des fichiers multimembres ne limite en rien les possibilits de traitements. Les mmes oprations peuvent tre effectues sur ces fichiers, et sur leurs donnes, que sur les fichiers monomembres. Toutefois, certaines limitations peuvent apparatre dans des cas particuliers faisant rfrence des standards dfinis hors de lOS/400 tels que SQL ou NFS (qui permet le partage de fichiers avec dautres systmes dexploitation comme Unix, par exemple). Il faut avoir lesprit que cette notion de membre est spcifique lAS/400. Elle est extrmement performante mais est ignore des autres systmes. Au fur et mesure que louverture de lOS/400 se concrtise, on se rend compte que la notion de membre nest pas supporte par les nouvelles fonctionnalits. Pour citer un exemple rcent, nous pouvons rappeler que lun des apports majeurs de la version V3R1M0, pour la base de donnes de lOS/400, est la possibilit de crer des contraintes dintgrit rfrentielle. Cette fonction, tant attendue, ne supporte pas les fichiers multimembres.
75
Pour lutilisation dans un environnement AS/400 (ou avec Client Access/400), il ny a pas de contraintes lutilisation de fichiers multimembres. En revanche, ils sont proscrire si lon dsire travailler en liaison avec dautres plates-formes. Lors de lanalyse, il est donc important de dfinir si les applications auront fonctionner dans un environnement o les donnes seront rparties sur plusieurs systmes, avant denvisager lutilisation de fichiers multimembres.
Les fichiers sources

Les fichiers sources constituent un bon exemple de fichiers multimembres. Ce sont des fichiers physiques classiques qui ont la particularit davoir trois zones : une contenant le numro de ligne, une autre correspondant la ligne de source proprement dite et la troisime indiquant la date de cration ou de dernire modification de cette ligne. Chaque source dun programme ou dun fichier est plac dans un membre. La commande CRTSRCPF permet de crer un fichier source. La longueur par dfaut de lenregistrement est de 92 (6 pour le numro de ligne, 80 pour le source et 6 pour la date). Avec des langages comme le RPG IV qui peuvent avoir des spcifications dune longueur de 100 colonnes, il faut prvoir une longueur denregistrement de 112.
Mise en uvre Cration

Le paramtre MBR de la commande CRTPF dfinit le nom du premier membre ajout lors de la cration du fichier physique. La valeur par dfaut fait rfrence au nom du fichier. Ainsi le membre et le fichier ont, en standard, le mme nom. La valeur MBR(*NONE) prcise quaucun membre nest cr avec le fichier. Un fichier physique ne peut tre cr quavec un membre, au maximum. Si lon dsire doter ce fichier de plusieurs membres, il faudra rajouter les suivants en excutant des commandes lances ultrieurement (ADDPFM). Le paramtre MAXMBR indique le nombre maximal de membres que peut possder ce fichier. Par dfaut, sa valeur est MAXMBR(1) : un seul membre peut tre
76
associ ce fichier. La commande CHGPF permet de modifier cette valeur ultrieurement, lorsque le besoin dun nouveau membre se fait sentir.
R FMT1 Z1 Z2 Z1
SOURCE
CRTPF FILE(PF1) MBR(*FILE) MAXMBR(1)
CRTPF FILE(PF1) MBR(PARIS) MAXMBR(2)
CRTPF FILE(PF1) MBR(*NONE) MAXMBR(2)
PF1 CHGPF FILE(PF1) MAXMBR(2) ADDPFM FILE(PF1) MBR(LYON)
PARIS ADDPFM FILE(PF1) MBR(LYON)
PF1 LYON
LYON
PARIS LYON
Figure 3.7 : exemples de cration de fichiers multimembres.
La commande ADDPFM ajoute un membre (et un seul la fois) un fichier physique. La figure 3.7 reprsente les diffrentes tapes de la cration dun fichier multimembre. Le nombre de membres que peut contenir un fichier dpend des versions de lOS/400 : ce jour, on peut considrer quil est quasiment infini (32 767).
Visualisation
Le contenu dun membre peut tre visualis, ou imprim, par la commande DSPPFM. Le rsultat est fourni soit en mode caractre, soit en reprsentation hexadcimale. Il faut utiliser la deuxime reprsentation pour interprter correctement les zones de type Dcimal condens. Cette commande est trs pratique lorsque lon dsire vrifier si une opration sest bien droule, mais elle est vite limite lors dune utilisation plus pousse. Il nous
77
semble alors prfrable dutiliser Query, par exemple, qui formate correctement les donnes dcimales, laide de la commande suivante :
RUNQRY QRYFILE(FICH1)
o FICH1 est le nom du fichier dont on dsire visualiser le contenu.
Slection dun membre

Dans un programme RPG, les spcifications F dfinissent les fichiers utiliser, mais, rien ne permet de donner le nom du membre slectionner. Par dfaut, les programmes traitent le premier membre du fichier (celui qui a t cr avec le fichier ou par la premire commande ADDPFM). Pour grer un autre membre, il faut au pralable (et de manire externe au programme) utiliser la commande de substitution de fichier OVRDBF. Cette dernire permet notamment de traiter un membre spcifique pour un fichier. Toute opration du travail en cours sur les donnes de ce fichier se drouleront sur le membre ainsi dfini. Cest le seul moyen mis notre disposition pour quun programme puisse accder aux donnes dun membre. Lexemple 3.11 du chapitre suivant prsente cette substitution.
Exemple
Lexemple 3.11 prsente un programme RPG qui utilise un fichier multimembre pour visualiser la quantit dun article en stock. Dans un premier temps, un programme en langage de contrle propose lutilisateur de saisir le nom du stock traiter et le numro de larticle visualiser. La commande de substitution permet de slectionner le membre qui a le mme nom que le stock. Le programme RPG lanc la suite ne verra que les enregistrements de ce membre. Il ne connat que le nom du fichier ; cest au niveau du programme CLP que la slection du membre est effectue. Le numro de larticle, la quantit en stock et le libell sont passs en paramtres. Algorithme
Appel du programme principal (CLP1) Affichage de lcran de saisie Substitution Appel du programme de traitement (RPG1) Affichage de la quantit
78
DDS du fichier physique

R NOM FMTF1 NUMART LIBEL QTE NUMART LG 6 15 6 FONCTION TEXT(Fichier FICH1)
DDS du fichier daffichage

R FMT2 1 6 7 10 11 I 6 I 7 O 10 2O 11 DSPSIZ(24 80 *DS3) OVERLAY 31'GESTION DES ARTICLES' COLOR(WHT) 5'Nom du stock:' 5'Code de l''article:' 5'Libell:' 5'Quantit:' 26 26 OVERLAY 26 26
STOCK NUMART R FMT3 LIBEL QTE R FMT1
10 6 15 6
23 38'F3=Fin' COLOR(BLU)
Reprsentation du fichier daffichage
GESTION DES ARTICLES Nom du stock: Code de larticle: Libell: Quantit: Format FMT2 Format FMT3 Format FMT1
F3=Fin
79
Source du programme principal

PGM /*Affichage de la quantit dun produit dans un stock*/ DCLF ECRAN DEBUT: SNDF RCDFMT(FMT1) /*Affichage de la ligne du bas*/ SNDRCVF RCDFMT(FMT2) /*Demande du stock et du code article*/ IF &IN03 GOTO FIN OVRDBF FILE(FICH1) TOFILE(*FILE) MBR(&STOCK) CALL PGM(RPG1) PARM(&NUMART &QTE &LIBEL) SNDRCVF RCDFMT(FMT3) /*affichage du rsultat*/ IF (*NOT &IN03) GOTO DEBUT FIN: /*Traitement de fin*/ ENDPGM
Source du programme RPG/400

FFICH1 IF E K DISK C *ENTRY PLIST C PARM NUMART 6 C PARM QTE 62 C PARM LIBEL 15 *ACCES SUR LA CLE C NUMART CHAINFMTF1 50 *SI LINDICATEUR 50 EST EN FONCTION IL Y A UN PROBLEME *AUCUNE GESTION DES ERREURS C RETRN
Exemple 3.11 : utilisation dun fichier multimembre. Par souci de lisibilit, aucun contrle de la saisie nest effectu.
Conclusions
Les fichiers multimembres constituent un bon outil pouvant apporter un important gain de productivit, surtout sil sont prvus ds la phase danalyse de la base de donnes. Ils ont quelques limitations dues certaines fonctionnalits ou certains produits issus de systmes o la notion de membre nexiste pas. Il est probable que louverture de lOS/400 se fera au dtriment de lutilisation des membres qui savraient tre une excellente solution pour rpondre aux besoins de linformatique de gestion, domaine de prdilection des premiers AS/400.
La gestion des fichiers physiques

Nous allons maintenant passer en revue les principales commandes qui permettent de grer les fichiers physiques.
80
Dfinition
Les caractristiques du fichier physique sont dfinies sa cration par la commande CRTPF, mais elles peuvent tre modifies par la suite laide de la commande CHGPF. Les modifications ainsi apportes sont permanentes et valables pour tous les utilisateurs. La substitution, par la commande OVRDBF, permet de modifier les caractristiques dun fichier pour le travail en cours seulement. Le chapitre 7 traite de ce sujet en dtail pour tous les types de fichier.
Destruction
Un fichier, quel quil soit, et condition davoir les droits suffisants, peut tre dtruit par la commande DLTF. Il est alors irrcuprable. RMVM enlve un membre, dtruisant ainsi les enregistrements quil contient. La structure du fichier est conserve car sa partie descriptive nest pas touche. On prfrera cette commande DLTF chaque fois quil sagira de dtruire un fichier pour le recrer par la suite. Enlever un membre est beaucoup plus rapide que la destruction complte dun fichier et, surtout, ajouter un membre un fichier existant nest rien par rapport la cration dun nouveau fichier.
CLRPFM
dtruit les enregistrements dun membre tout en conservant vide le membre lui-mme.
Visualisation
Les caractristiques gnrales dun fichier sont visualisables (ou mme imprimables) par la commande DSPFD. On peut ainsi connatre toutes les valeurs dfinies pour les paramtres de la commande CRTPF ou ventuellement de CHGPF. En revanche, DSPFFD, dont la syntaxe est proche, affiche le dtail de toutes les zones qui composent le fichier.
DSPPFM affiche le contenu dun membre. On peut ainsi trs simplement voir les enregistrements rangs dans ce membre. Seules les donnes de type Alphanumrique sont clairement visualisables ; une petite gymnastique est indispensable pour interprter les zones dautres types (le Dcimal condens, par exemple).
Modification de la structure
DB2/400 ne permet pas de modifier dynamiquement la structure dun fichier physique. Pour ajouter une zone, ou pour en modifier la longueur, il faut passer par
81
les DDS, cest--dire modifier le source du fichier physique existant, puis recompiler ce source. Cette opration, qui semble relativement aise, est lourde de consquences car, pour crer un nouveau fichier, il faut avoir dtruit lancien au pralable. Si lon ny prend garde, voici les problmes qui peuvent tre rencontrs : les donnes de lancien fichier sont perdues ; la scurit mise en place disparat ; les caractristiques de lancien fichier sont redfinir dans le nouveau (nombre de membres autoriss, date dexpiration...) ; les programmes qui utilisent ce fichier devront tre recompils si lidentificateur de format du fichier a t modifi (ce qui est probablement le cas) ; les fichiers logiques dfinis sur ce fichier physique doivent tre dtruits au pralable, car le fichier physique ne peut lui-mme tre dtruit si un fichier logique pointe dessus ; la journalisation ne permettra pas de revenir sur les oprations effectues sur lancien fichier... Voici les diffrentes tapes respecter : dune manire gnrale, il est important de sauvegarder toutes les informations associes au fichier. Le plus simple consiste copier ce fichier grce la commande CRTDUPOBJ, en prcisant DATA(*YES) pour que les donnes soient dupliques dans le nouvel objet. La sauvegarde classique est inefficace car la restauration standard remplace le nouveau fichier par lancien, ce qui nest pas le rsultat escompt. Les donnes et les caractristiques du fichier sont donc prsentes dans lobjet rsultant de la copie. Il est important darrter les travaux qui pourraient modifier les donnes du fichier dorigine ou de le verrouiller en mode exclusif ; les fichiers logiques qui pointent sur le fichier physique doivent tre dtruits par la commande DLTF. On aura pris soin de vrifier que les sources sont toujours disponibles. La commande DSPDBR permet de connatre tous les fichiers logiques qui pointent sur un fichier physique. Elle peut renvoyer la liste lcran, et surtout dans un fichier, ce qui permet dautomatiser compltement toutes ces oprations. LAPI QDBLDBR donne des informations comparables travers un User Space (objet de type *USRSPC), mais les traitements sont beaucoup plus rapides. Il faut absolument noter les caractristiques de chacun
82
des fichiers logiques pour pouvoir les recrer lidentique, surtout en ce qui concerne les membres ; le fichier physique peut ensuite tre dtruit par la commande DLTF ; aprs modification des DDS, il peut tre recompil. On prendra soin de paramtrer correctement cette commande pour que le nouvel objet ait les mmes caractristiques que lancien (consulter par DSPFD la description de la copie pour voir le nombre maximal de membres, la date dexpiration...). Ce nest pas la peine de crer un membre, car la copie de ltape suivante le fera automatiquement ; mettre ventuellement en place la scurit sur ce nouvel objet ; copier les donnes partir de lobjet dupliqu laide de la commande CPYF. Les valeurs suivantes sont importantes : FROMMBR(*ALL) afin de copier les donnes de tous les membres, TOMBR(*FROMMBR) pour conserver la mme structure au niveau des membres, MBROPT(*ADD) pour ajouter les enregistrements dans le fichier de destination, FMTOPT(*MAP *DROP) pour une copie intelligente, de zone zone. Aprs cette opration, les donnes sont dans le nouveau fichier, les nouvelles zones ont t initialises avec la valeur par dfaut ; les fichiers logiques peuvent tre recrs ; les programmes grant les fichiers dont lidentificateur de format a t modifi doivent tre recompils ; le fichier dupliqu peut tre dtruit ; une sauvegarde de ce fichier (et ventuellement des chemins daccs des fichiers logiques) peut tre lance. Lexemple 3.12 prsente la structure dun programme automatisant la recration du fichier physique et des fichiers logiques dpendants. Programme secondaire CRTPFLF
PGM /*CRTPFLF*/
83
/*APPEL PAR DLTPFLF*/ /*PROGRAMME AUTOMATISANT LA RECREATION DE LF*/ /*FONCTIONS DE BASES SEULEMENT, A ENRICHIR SELON LES BESOINS*/ DCLF LECT: RCVF MONMSG MSGID(CPF0864) EXEC(GOTO FIN2) CRTLF FILE(&WHRELI/&WHREFI) /*CREATION DU LOGIQUE*/ GOTO LECT FIN2: ENDPGM FILE(DBR) /* OUTFILE DE DSPDBR*/
Programme principal
PGM PARM(&FICH &BIB) /*PROGRAMME DLTPFLF*/ /*PROGRAMME AUTOMATISANT LA DESTRUCTION D'UN PF ET DES LF ASSOCIS*/ /*FONCTIONS DE BASES SEULEMENT, A ENRICHIR SELON LES BESOINS*/ /*RECONSTRUCTION DES LOGIQUES AVEC VALEURS PAR DEFAUT*/ DCLF QSYS/QADSPDBR DCL &FICH *CHAR 10 DCL &BIB *CHAR 10 DCL &DBR *CHAR 10 CRTDUPOBJ DSPDBR OVRDBF LECT: RCVF /* POUR LE FORMAT DU OUTFILE DE DSPDBR*/ /*NOM DU PF A RECOMPILER*/ /*NOM DE LA BIBLIOTHEQUE DU PF*/ 'DBR' /*DU FICHIER RECEVANT LA SORTIE DE DSPDBR*/
OBJ(&FICH) FROMLIB(&BIB) OBJTYPE(*FILE) + TOLIB(*CURLIB) NEWOBJ(FICHDUP) DATA(*YES) FILE(&BIB/&FICH) OUTPUT(*OUTFILE) OUTFILE(&DBR) FILE(QADSPDBR) TOFILE(&DBR) MONMSG MSGID(CPF0864) EXEC(GOTO FIN1) DLTF (&WHRELI/&WHREFI) /*DESTRUCTION DU LOGIQUE*/ GOTO LECT
FIN1: DLTF (&BIB/&FICH) /*DESTRUCTION DU PHYSIQUE*/ CRTPF FILE(&BIB/&FICH) /*RECREATION DU PHYSIQUE*/ /*LE SOURCE DOIT EXISTER DANS QDDSSRC*/ CPYF FROMFILE(FICHDUP) TOFILE(&BIB/&FICH) + FROMMBR(*ALL) TOMBR(*FROMMBR) + MBROPT(*ADD) FMTOPT(*MAP *DROP) DLTOVR QADSPDBR CALL CRTPFLF /*CREATION DES LOGIQUES*/ DLTF (&DBR) DLTF (FICHDUP) ENDPGM
Exemple 3.12 : recration automatique dun physique et des logiques associs. Le programme DLTPFLF place les noms des fichiers logiques dpendant du fichier physique dtruire dans le fichier DBR, dtruit tous les fichiers logiques et lance DLTPFLF2 pour la recration de ces fichiers.
84
Pour conclure sur une note optimiste, il faut signaler que la prochaine version de lOS/400 (V3R6M0 et volution de la V3R1M0) devrait nous permettre de modifier dynamiquement la structure dun fichier physique (et dune table avec ALTER TABLE).
Les membres
permet dajouter un membre un fichier physique et RMVM de lenlever. Les caractristiques dun membre peuvent tre modifies grce CHGPFM. Il sagit essentiellement du commentaire qui lui est associ et de la date de premption de ses enregistrements. Il faut utiliser RNMM pour renommer un membre.
ADDPFM
Il faut utiliser INZPFM pour ajouter un certain nombre denregistrements vierges un membre. La valeur par dfaut est prise pour les zones qui ont t codifies dans les DDS avec le mot-cl DFT, sinon, les zones de type Alphanumrique sont remplies par des blancs et les zones numriques sont initialises avec la valeur 0.
Sauvegarde
Les fichiers physiques doivent tre rgulirement sauvegards car ils contiennent les donnes, nous y reviendrons. Les commandes de sauvegarde et de restauration classiques sappliquent aux fichiers (SAVOBJ, SAVLIB, RSTOBJ, RSTLIB...). Il faut ajouter que les chemins daccs peuvent aussi tre sauvegards. Non pas quils soient indispensables, aucune donne nest perdue lors de la destruction dun chemin daccs, mais parce que leur reconstruction peut prendre un temps considrable. Il est donc intressant de sauvegarder les chemins daccs des gros fichiers pour gagner plusieurs heures lors de leur ventuelle restauration (paramtre ACCPTH). Il est noter quil est prfrable davoir le fichier physique et les fichiers logiques qui pointent dessus dans la mme bibliothque, pour faciliter la restauration des chemins daccs.
Rorganisation
La commande RGZPFM rorganise un membre dun fichier physique. Les trous laisss par les enregistrements marqus leffacement sont ainsi rcuprs et les chemins daccs sont rorganiss. Dune manire gnrale, les temps daccs un fichier rorganis sont bien meilleurs.
85
Cette opration est indispensable pour les fichiers haute activit qui subissent de frquentes modifications, insertions ou suppressions. Mais, elle est considrer avec attention car elle touche au contenu mme du fichier. Il faut toujours rorganisation. effectuer une sauvegarde avant une
Les utilitaires
Query, lanc par STRQRY, est loutil idal pour gnrer rapidement un tat en sappuyant sur les donnes dun ou de plusieurs fichiers. DFU (data file utility) est loutil destin bricoler les fichiers. Il gnre trs simplement un petit programme qui permet de travailler directement avec les enregistrements des fichiers. Cette simplicit masque le danger. On peut ainsi modifier ce que lon veut, o lon veut, dans la base de donnes, condition den avoir les droits videmment ! La cohrence entre les donnes de diffrents fichiers peut ainsi tre perdue. DFU est donc rserver des cas particuliers, o on agit en toute connaissance de cause et o le bricolage est de rigueur. SQL est trait plus loin dans cet ouvrage car il dpasse le cadre dun simple utilitaire. Il permet, en interactif, en batch et dans des programmes, de grer les donnes en local ou distance sur dautres AS/400 et mme celles situes dans des environnements diffrents tels que DB2/2 sous OS/2, DB2/6000 sous AIX, DB2 sous MVS... Il faudrait ajouter cette liste bien dautres utilitaires car la base de donnes est totalement intgre lOS/400. Citons Client Access/400, anciennement PCS/400, qui extrait les donnes des fichiers partir dun micro-ordinateur, et Office Vision qui fusionne les enregistrements avec du texte.
Conclusions
Les fichiers physiques constituent le fondement de la base de donnes de lAS/400 car ils contiennent les donnes, et ce sont les seuls pouvoir le faire. Un soin particulier doit tre donn leur analyse, afin quils soient le plus optimiss possible, et leur gestion, pour quils restent performants. Enfin, leur sauvegarde doit tre rgulire pour prvenir toute perte dinformation.
86
De nombreuses fonctions, telles que la journalisation et le contrle de validation, pourront tre mises en uvre afin de conserver lintgrit des donnes. Elles seront soutenues par des dispositifs physiques comme les disques miroirs, le contrle dintgrit et les disques RAID 5. Nous y reviendrons...
Les principales commandes

ADDPFM CHGPF CHGPFM CLRPFM CPYF CRTDUPOBJ CRTPF CRTSRCPF DLTF DSPDBR DSPFD DSPFFD DSPPFM EDTRBDAP OVRDBF OVRPRTF RGZPFM RMVM RNMM RUNQRY STRDFU STRQRY STRSQL WRKF
ajouter un membre un fichier physique ; modifier les caractristiques dun fichier physique ; modifier les caractristiques dun membre dun fichier physique ; enlever les enregistrements dun membre dun fichier physique ; copier un fichier ; crer un objet dupliqu ; crer un fichier physique ; crer un fichier source ; dtruire un fichier ; afficher les relations dun fichier ; afficher la description dun fichier ; afficher la description des zones dun fichier ; afficher le contenu dun membre ; rviser les chemins daccs en cours de rtablissement ; substituer un fichier base de donnes ; substituer un fichier dimpression ; rorganiser un membre dun fichier physique ; enlever un membre ; renommer un membre ; lancer un programme Query ; dmarrer DFU ; dmarrer Query ; dmarrer SQL interactif ; grer les fichiers.
Les principaux menus

FILE, FILE2, CMDPF, CMDFILE, CMDMBR, CMDDBF, CMDDB.
87
LES FICHIERS PHYSIQUES ..........................................................................................29 LES ETAPES DE LA CREATION D'UN FICHIER PHYSIQUE PAR DDS ...........................................30 LA CODIFICATION DES FICHIERS PHYSIQUES ..........................................................................30 Principes ..........................................................................................................................31 Le dictionnaire .................................................................................................................31 Les cls .............................................................................................................................33 Liens avec les fichiers d'affichage....................................................................................37 Partage de format ............................................................................................................40 Valeur par dfaut .............................................................................................................41 En-tte de colonne............................................................................................................42 Le traitement des dates.....................................................................................................44 Les zones de longueur variable........................................................................................46 Environnement multinational...........................................................................................48 Les principaux mots-cls des DDS ...................................................................................49 LA COMMANDE DE CREATION DE FICHIERS PHYSIQUES .........................................................51 Dfinition du fichier .........................................................................................................51 Cration d'un fichier sans DDS........................................................................................52 Gravit des messages .......................................................................................................52 Les membres.....................................................................................................................53 Le chemin d'accs ............................................................................................................53 Ecriture force en mmoire secondaire ...........................................................................56 Les fichiers physiques et la mmoire secondaire .............................................................57 Les verrouillages ..............................................................................................................60 Le partage du bloc de contrle (ODP).............................................................................61 Les groupes dactivation et lODP...................................................................................66 Les enregistrements dtruits.............................................................................................66 Lidentificateur de format ................................................................................................67 Les oprations permises ...................................................................................................68 Le tri.................................................................................................................................69 Conclusions ......................................................................................................................70 Les principaux paramtres de la commande CRTPF.......................................................70 LES MEMBRES .......................................................................................................................72 Gnralits .......................................................................................................................73 Mise en uvre ..................................................................................................................75 Exemple............................................................................................................................77 Conclusions ......................................................................................................................79 LA GESTION DES FICHIERS PHYSIQUES ...................................................................................79 Dfinition .........................................................................................................................80 Destruction.......................................................................................................................80 Visualisation.....................................................................................................................80 Modification de la structure.............................................................................................80 Les membres.....................................................................................................................84 Sauvegarde.......................................................................................................................84 Rorganisation .................................................................................................................84
88
Les utilitaires....................................................................................................................85 CONCLUSIONS .......................................................................................................................85 LES PRINCIPALES COMMANDES .............................................................................................86 LES PRINCIPAUX MENUS ........................................................................................................86
A
ABSVAL 33 ACCPTH 80 ACTGRP 63 ADDPFM 71; 72; 80 ALLOCATE 55 ALTSEQ 35; 66 ALWDLT 65 ALWNULL 45 ALWUPD 65 ALWVARLEN 45 avec ALTER TABLE
79 avec Client Access/400 71
C
CCSID 47; 66 CHECK 37 chemin daccs 69 chemin d'accs 51 CHGPF 67 CHGPFM 80 CHKMSGID 37 cl 33 CLRPFM 76 COLHDG 41 COMP 37 CPYF 40; 45; 78 CRTDUPOBJ 77 CRTEDTD 38 CRTPF 30; 49
D
Date 42
DATFMT 42 DATSEP 42
DB2 42 DCLF 45
30
DDS 30; 47 DESCEND 34 DFT 40 DFU 81 dictionnaire 31 DLTEDT 39 DLTF 76 DLTPCT 64 DSPFD 35; 56; 76 DSPFFD 76 DSPPFM 72; 76
E
EBCDIC 46 EDTCDE 38 EDTRBDAP 54 EDTWRD 38 EXIT 62 EXPCHK 66 EXPDATE 51; 65
F
fichier d'affichage 36 fichier physique 29 fichier source 71 FIFO 34; 64 FILETYPE 50 FLAG 51 FORMAT 39 FRCACCPTH 53 FRCRATIO 53; 54
G
GENLVL 50 groupe dactivation 63
H
Horodatage 43
I
IDDU 29
31
identificateur de format 64 ILE 42 imestamp 43 INZPFM 40; 80
J
JDFTVAL 40 journalisation 69
L
l'ASCII 46 l'IPL 54 LANGID 35; 66 LIFO 64 LIFO 34 longueur variable 44 LVLCHK 64
M
MAINT 52 MAXMBR MBR 51
51; 71
membre 68 monomembre 70 multimembre 70
N
NFS 70
NOALTSEQ NULL 45
35; 66
O
ODP 58
OPNQRYF 45; 65 OVRDBF 59; 62; 65; OVRDSPF 65 OVRPRTF 65
66; 73
P
PAG 59 page de code 46
32
Partage de format 39
Q
QCASE256 35 QDBLDBR 77 QDDSSRC 49 QGPL 49 QSYS 66 QSYSOPR 55
Query 45; 73; 81 QUSRSYS 35
R
RANGE 37 RECOVER 53 REF 31; 36 REFFLD 31; 36 REFSHIFT 37 RETRN 62 REUSEDLT 64 RGZPFM 64; 80 RMVM 76; 80 RNMM 80
RPG IV 44 RPG/400 43; 45 RSTLIB 80 RSTOBJ 80
S
SAVLIB 80 SAVOBJ 80 SHARE 60 SIZE 55
SQL 45; 70; 81 SQL/DS 42 SRCMBR 49 SRTSEQ 35; 66 STOPRUN 62 STRQRY 81 STRSST 56
33
T
table de conversion 66 Time 42 Timestamp 42 TIMFMT 42 TIMSEP 42 tri 34; 66
U
UNIQUE 34; UNIT 56
52
User Space 77
V
Valeur par dfaut 40 VALUES 37 VARLEN 44 verrouillage 58
W
WAITFILE 58 WAITRCD 58
Chapitre 4
Les fichiers logiques
Principes
Prsentation
Les fichiers logiques constituent lun des composants essentiels de la base de donnes de l'OS/400. Ils ne contiennent pas rellement des donnes, mais laissent voir les enregistrements des fichiers physiques d'une certaine manire (tris sur une zone, par exemple). Ils permettent donc une indpendance entre les donnes (dans les fichiers physiques) et l'utilisation que l'on peut en faire (par les programmes). L'organisation gnrale de la base de donnes DB2/400 est rsume par la figure 4.1.
Structure
Les fichiers logiques ne contiennent pas rellement les donnes, nous l'avons dj signal. Les enregistrements renvoys aux programmes proviennent en fait des fichiers physiques, ils sont seulement mis en forme au travers du fichier logique. Il n'y a donc pas duplication de l'information (aussi appele redondance). C'est une des caractristiques des systmes de gestion de base de donnes relationnelle (SGBDR).
84
PGM1
PGM2
PGM3
PROGRAMMES
NUMCLI
VILLE
CODEP
NUMCLI
NOMCLI NUMFACT
TOTAL
NIVEAU LOGIQUE (VUES)
Cl: NUMCLI
Cl : NUMCLI
NUMCLI
NOMCLI
VILLE
CODEP
NUMFACT
NUMCLI
DATE
TOTAL
NIVEAU PHYSIQUE (DONNEES)
Figure 4.1 : organisation des donnes avec DB2/400.
Mais alors, que contient un fichier logique ? De manire thorique, tout ce passe comme si le fichier logique contenait seulement la phrase dfinissant les donnes que l'on voit ; par exemple, voir les donnes du fichier PF1, tries sur la zone NUMCLI, par ordre dcroissant . Cette image, certainement caricaturale, montre qu'en dtruisant un fichier logique, on ne dtruit aucune donne mais seulement la "phrase" dcrivant ce qui est vu. En fait, chaque membre d'un fichier logique possde un chemin d'accs qui lui permet d'atteindre rapidement les donnes du (ou des) fichier(s) physique(s). Ce chemin d'accs ne pointe que sur les enregistrements qui correspondent aux critres de slection, tris selon la cl du fichier logique (figure 4.2). Un chemin d'accs de fichier logique a une structure identique celui dun fichier physique. C'est un index qui contient la cl (si elle existe) de chaque enregistrement vu par le fichier, et organis selon l'ordre, croissant ou dcroissant, dfini dans les DDS. Les enregistrements lus dans un fichier logique apparaissent donc tris sur la cl. On peut toutefois noter une lgre diffrence entre les chemins daccs des fichiers physiques et ceux des fichiers logiques : les premiers voient tous les enregistrements du membre concern, alors quavec les seconds seuls les enregistrements qui correspondent aux critres de slection (s'ils existent) sont pris en compte.
4 - Les fichiers logiques
85
PGM1
Fichier logique LF1
NOMCLI SOLDE SOLDE > 1000 CLE : NOMCLI
CHEMIN DACCES de LF1 CLE DUMONT DUPOND ADRESSE
NUMCLI 21 12 35 24 15 56
NOMCLI DUPOND CHRISTOPHE DUMONT DUMAS FERRET JACQUART
SOLDE 6000 500 5000 20 12 120
Fichier physique PF1
Figure 4.2 : reprsentation schmatique du chemin d'accs d'un fichier logique. Le programme PGM1 ne verra que les deux enregistrements prsents dans le chemin daccs.
Utilisation
Dans les programmes, et d'une manire gnrale, un fichier logique est utilis comme un fichier physique. Les dclarations sont identiques pour ces deux types de fichiers dans tous les langages de programmation (Langage de contrle, RPG, Cobol...), ainsi que les ordres de lecture et ventuellement d'criture. L'utilisation de l'un ou de l'autre type de fichier est totalement transparente pour les programmes. Les fichiers logiques peuvent tre utiliss pour de nombreuses raisons. Voici les principales : pour assurer l'indpendance entre les programmes et les donnes ; pour la scurit ; pour un meilleur accs aux donnes ; et enfin, pour rpondre certaines contraintes lies la programmation. Nous allons maintenant dtailler ces diffrentes utilisations.
86
Indpendance programmes donnes

La modification de la structure d'un fichier physique entrane la modification de son identificateur de format. Il faut donc recompiler tous les programmes qui utilisent ce fichier sous peine de voir apparatre le message CPF4131 (chapitre 3, La commande de cration de fichiers physiques). Cette tche est parfois dlicate pour peu que certaines caractristiques de ces programmes ne soient pas standards (version particulire du compilateur, observabilit...). Les fichiers logiques peuvent servir de tampon entre les programmes et les fichiers physiques. Il est alors possible, et sous certaines conditions, de modifier la structure des fichiers physiques sans avoir recompiler les programmes qui grent leurs donnes. Si un nouveau besoin pour l'entreprise se traduit par la ncessit d'ajouter une zone un fichier physique utilis directement par un programme, il faut procder comme suit (figure 4.3) : modification de la structure du fichier physique (voir ce sujet la section La gestion des fichiers physiques Modification de la structure du chapitre 3). Il faut notamment prendre garde au fait que la recration du fichier physique saccompagne de la destruction de lobjet existant, ce qui conduit la perte de toutes les donnes. Une copie pralable de ces donnes dans un autre fichier est donc indispensable ; recompilation du programme (et de tous les programmes qui utilisent ce fichier).
3 - RECOMPILATION DU PROGRAMME
PGM1
1 - MODIFICATION DES DDS 2 - CREATION DU FICHIER NUMCLI NUMFACT MONTANT NUMCLI
PGM1
NUMFACT
MONTANT
DEVISE
Figure 4.3 : modification du format d'un fichier physique et recompilation du programme.
Si, par contre, le programme utilise le fichier logique LF1 (figure 4.4), les tapes suivre sont :
87
destruction des fichiers logiques pointant sur PF1, en ayant pris soin de conserver les sources contenant les DDS de ces fichiers ; Cette tape est indispensable car il est impossible de dtruire un fichier physique sur lequel pointe un fichier logique. modification de la structure du fichier PF1 ; recration du fichier physique puis, des fichiers logiques.
PGM1
LF1
1- DESTRUCTION DU FICHIER LOGIQUE 4 - RECOMPILATION DU FICHIER LOGIQUE
LF1
2 - MODIFICATION DES DDS 3 - CREATION DU FICHIER PHYSIQUE NUMCLI NUMFACT MONTANT NUMCLI NUMFACT MONTANT DEVISE
Figure 4.4 : modification du format d'un fichier physique sans recompilation du programme.
L'indpendance entre les programmes et les donnes est ainsi prserve : la structure des donnes a t modifie sans qu'il soit besoin de recompiler les programmes. Par contre, le travail de gestion des fichiers logiques (destruction, recompilation) est plus fastidieux, mais peut tre entirement automatis. Cette indpendance n'est relle que sous une certaine contrainte : l'identificateur de format du fichier logique doit tre conserv. Autrement dit, les caractristiques des zones vues au travers de ce fichier ne doivent pas changer. Dans l'exemple 4.5, il faut recompiler le programme car la structure de la zone NUMCLI est modifie, ce qui entrane un changement pour l'identificateur de format de LF1.
Scurit
Les fichiers logiques permettent de donner l'accs une partie des zones constituant le format des fichiers physiques. Ils sont donc conseiller lorsque l'on
88
doit mettre la disposition de certains utilisateurs une partie seulement de chaque enregistrement. Par exemple, pour le fichier de la paie, certaines personnes doivent pouvoir accder au nombre de jours de vacances dj pris par chaque employ, mais elles ont interdiction de visualiser le montant du salaire de ces mmes employs. La figure 4.6 rsume cette situation. Au travers du fichier logique CONGELF, ces utilisateurs ne voient que les zones correspondant aux congs et ne peuvent pas accder aux donnes sensibles sur les salaires.
PGM1
5 - RECOMPILATION DU PROGRAMME
PGM1
1- DESTRUCTION DU FICHIER LOGIQUE 4 - RECOMPILATION DU FICHIER LOGIQUE
LF1
NUMFACT MONTANT CLE : NUMFACT
LF1
NUMCLI 5
NUMFACT 6
MONTANT 7 dont 2
NUMCLI 5
NUMFACT 6
MONTANT 9 dont 2
DEVISE 3
2 - MODIFICATION DES DDS 3 - CREATION DU FICHIER PHYSIQUE
Figure 4.5 : modification du format d'un fichier physique et recompilation du programme malgr la prsence d'un fichier logique. Le format de la zone MONTANT, de type Dcimal condens, passe de longueur 7 dont 2 9 dont 2. Lidentificateur de format de LF1 est donc modifi et il faut recompiler le programme PGM1.
Il existe une limitation contraignante lutilisation des fichiers logiques pour la scurit : un utilisateur doit avoir les droits suffisants sur les donnes du fichier physique. Depuis la version V3R1M0 de lOS/400, les fichiers logiques peuvent aussi avoir des droits sur les donnes. Le systme vrifie dabord si les droits sur les donnes du fichier logique sont suffisants, puis il opre la mme vrification pour le fichier physique. Autrement dit, pour quun utilisateur puisse voir des donnes travers un fichier logique, il faut : quil ait les droits ncessaires sur les donnes du fichier logique ; quil ait les droits ncessaires sur les donnes du fichier physique. Dans lexemple ci-dessus, les utilisateurs concerns ont les droits suffisants sur les donnes du fichier physique pour la lecture. Rien ne les empche dattaquer
89
directement les donnes de PAIEPF avec Query ou SQL, ce qui va lencontre de la scurit puisquils peuvent voir toutes les zones de ce fichier ! On prendra donc soin dinterdire toute action directe sur le fichier physique en enlevant les droits *OBJOPR pour ces utilisateurs grce la commande EDTOBJAUT, par exemple. Malgr ces limitations, cette solution est probablement la meilleure lorsque l'on dsire donner un utilisateur laccs une slection de zones d'un enregistrement en lui interdisant les autres zones. Elle est aussi intressante lorsque l'on dsire accder une petite partie d'un gros enregistrement. La taille de l'ODP est ainsi rduite car les enregistrements traits par le logique sont plus petits.
PGMx DFU PCS/400 CA/400
QUERY SQL
NUMEMP NOMEMP CONGE
Fichier logique CONGELF
NUMEMP
NOMEMP
SALAIRE
ANCIENNETE
CONGE
Fichier physique PAIEPF
Figure 4.6 : protection d'une zone par un fichier logique. Les zones SALAIRE et ANCIENNETE ne seront pas accessibles partir du fichier logique CONGELF.
Rapidit d'accs
Dans un fichier physique, on ne peut dfinir qu'une seule cl. Si on dsire accder rapidement un enregistrement partir de la valeur de zones ne composant pas la cl, il faut crer des fichiers logiques pour dfinir de nouvelles cls. Chaque programme devra utiliser le fichier logique qui correspond la bonne cl. Si, ces fichiers logiques avec cl ont t dfinis avec le mot cl UNIQUE, alors plusieurs zones (ou combinaison de zones) ne pourront avoir la mme valeur dans deux enregistrements du fichier physique. Les fichiers logiques permettent de ne traiter que les enregistrements qui correspondent certains critres de slection (par exemple, les enregistrements
90
dont la valeur de la zone SALAIRE est suprieure 10 000). Ainsi, le programme n'a plus lire tous les enregistrements pour les tester et ventuellement les traiter. Chaque enregistrement vu au travers du fichier logique correspondant aux critres de slection, le gain de temps en traitement peut tre considrable. De plus, les programmes sont plus simples car ils sont dchargs de toute une srie de contrle.
Autres avantages
Les fichiers logiques nous permettent de voir les zones des fichiers physiques en modifiant leurs caractristiques : changement de type, de longueur ou de nom, extraction ou concatnation... Les programmes, par leur intermdiaire, peuvent continuer fonctionner alors que le fichier physique a t fortement modifi, ou mme qu'il a t remplac par un (ou des) autre(s).
Les diffrents types de fichiers logiques

Les fichiers logiques sont rpartis en deux familles, selon qu'ils effectuent ou non une jointure. Ce sont : les fichiers logiques non-joints ; et les fichiers logiques joints. Les fichiers logiques non-joints ne mettent pas en uvre la jointure. Les enregistrements peuvent tre vus travers un seul format. C'est le cas, par exemple, si les enregistrements proviennent d'un seul fichier physique ou si les zones sont prsentes dans tous les fichiers. Ces fichiers sont dits non-joints monoformat. Les enregistrements peuvent aussi tre vus sous plusieurs formats (un format pour chaque fichier physique). Les enregistrements de ces diffrents formats ont comme lien une mme valeur de cl. C'est le cas, par exemple, pour un fichier logique qui correspond une facture. Pour un numro de facture (valeur de cl), il verra un enregistrement du fichier ENTETE qui dcrit l'en-tte de la facture et de nombreux enregistrements du fichier DETAIL qui contiennent chacune des lignes de la facture. Ces deux fichiers sont vus travers des formats diffrents. Nous expliquerons plus loin le fonctionnement de ces fichiers non-joints multiformats.
91
Les fichiers logiques non-joints peuvent tre utiliss pour la lecture et pour la mise jour d'enregistrements (cration, modification et suppression). Les fichiers logiques joints mettent en uvre l'oprateur de jointure. Ils permettent de voir les enregistrements de 2 32 fichiers physiques, joints 2 2, sous un seul format. Les fichiers logiques joints peuvent tre utiliss uniquement pour lire les enregistrements. La mise jour travers de tels fichiers est impossible.
Les tapes de la cration d'un fichier logique

La cration de tous les fichiers logiques se droule comme pour les fichiers physiques, c'est--dire : cration d'un membre source de type LF. La spcification A est la mme que celle utilise pour les fichiers physiques ; compilation par la commande CRTLF. Le chemin daccs est constitu ds la cration du logique, ce qui explique que les fichiers physiques doivent tre prsents lors de cette tape. Un fichier logique ne peut exister sans la prsence des fichiers physiques sur lesquels il pointe. Nous allons prsent dcrire les principaux mots-cls des DDS utiliss pour les fichiers logiques non-joints, puis nous verrons la mise en uvre de la jointure.
Les fichiers logiques non-joints

Principes
92
Comme pour les fichiers physiques, nous verrons les DDS regroupes par thmes, en ne traitant que les mots-cls spcifiques aux fichiers logiques car beaucoup ont dj t vus avec les fichiers physiques. Une liste, la fin de ce chapitre, reprend toutes les DDS des fichiers logiques.
La rfrence aux fichiers physiques Fichier physique unique

Un fichier logique s'appuie obligatoirement sur au moins un fichier physique (et il ne peut s'appuyer que sur des fichiers physiques, pas sur des fichiers logiques). C'est le mot-cl PFILE qui dfinit le, ou les, fichiers physiques vus par le logique. L'exemple 4.1 dfinit un fichier logique qui voit les zones ZONEA et ZONEB du fichier physique PF1, de la bibliothque BIBPF. Les enregistrements apparatront tris sur ZONEA.
NOM R FMTLF1 ZONEA ZONEB K ZONEA LG DEC FONCTION PFILE(BIBPF/PF1)
Exemple 4.1 : dfinition du fichier physique vu par un fichier logique.
Si le fichier logique voit la totalit des zones du fichier physique, on peut omettre de citer toutes ces zones si le nom du format que l'on donne au fichier logique est le mme que celui du fichier physique (exemple 4.2). La description de toutes les zones est alors automatiquement ramene dans le logique. Mais, on ne peut alors codifier aucune nouvelle zone, ni changer leur ordre. La cl est dfinir, mme si elle existe dans le fichier physique, car seul le format est ramen, pas la cl.
NOM R FMTPF1 K ZONEA LG DEC FONCTION PFILE(BIBPF/PF1)
Exemple 4.2 : dfinition d'un fichier physique et rcupration de son format. Toutes les zones de PF1 sont vues au travers de ce logique. FMTPF1 est le format de PF1.
L'union
L'union, au sens relationnel du terme, est matrialise par les fichiers logiques non-joints monoformats. Ils permettent de voir les enregistrements de plusieurs fichiers physiques (jusqu' 32) au travers d'un mme format. Leur codification est
93
reprsente par l'exemple 4.3. Les zones cites dans le fichier logique doivent tre prsentes dans chacun des fichiers physiques.
NOM R FMTLF1 ZONEA ZONEB K ZONEA LG DEC FONCTION PFILE(PF1 PF2 PF3)
Exemple 4.3 : dfinition de l'union. ZONEA et ZONEB doivent tre prsentes dans PF1, PF2 et PF3.
Le format de l'un des fichiers physiques peut aussi tre rcupr dans sa totalit. Dans l'exemple 4.4, FMTPF1 est le nom du format de PF1, premier fichier cit aprs
94
le mot-cl PFILE. Toutes les zones de ce fichier composeront le logique. Dans l'exemple 4.5, le nom du format n'est pas celui du premier fichier cit dans PFILE, il faut alors indiquer le nom du fichier possdant ce format dans le mot-cl FORMAT.
NOM R FMTPF1 K ZONEA LG DEC FONCTION PFILE(PF1 PF2 PF3)
Exemple 4.4 : dfinition de l'union et rcupration du format du premier fichier cit dans PFILE. FMTPF1 est le format de PF1.
NOM R FMTPF2 K ZONEA LG DEC FONCTION PFILE(PF1 PF2 PF3) FORMAT(PF2)
Exemple 4.5 : dfinition de l'union et rcupration du format d'un fichier cit dans PFILE. FMTPF2 est le format de PF2.
La figure 4.7 montre comment sont vus les enregistrements d'un fichier logique non-joint monoformat pointant sur plusieurs fichiers physiques (union).
Slection et omission
Traditionnellement, un programme lit tous les enregistrements dun fichier et ne traite que ceux qui correspondent certaines contraintes. Si le fichier est gros, et si peu denregistrements correspondent au critres de slection, il est clair que le programme passe normment de temps lire et tester des enregistrements qui ne seront pas retenus. Les fichiers logiques nous permettent de ne voir que les enregistrements traiter. Le programme na plus soccuper de tester les enregistrements. Les gains, en termes de dveloppement, de performance, et mme de scurit, sont nets.
Seuls les enregistrements correspondant aux critres de slection figurent dans le chemin daccs dun fichier logique contenant des slections/omissions.
95
NUMART 1 1 1 2 2 2 3
QTITE 12 5 15 8 5 6 8
STOCK PARIS NIMES LYON PARIS NIMES LYON PARIS
R K
NOM STOCKF NUMART
FONCTION PFILE(STOCK94 STOCK95)
Fichier logique LF1

NUMART 1 1 1 1 1 1 2 2 2 2 2 2 3 3 QTITE 12 5 15 2 18 11 8 5 6 5 3 2 8 18 STOCK PARIS NIMES LYON PARIS NIMES LYON PARIS NIMES LYON PARIS NIMES LYON PARIS PARIS
Fichier physique STOCK94 format STOCKF

NUMART 1 1 1 2 2 2 3 QTITE 2 18 11 5 3 2 18 STOCK PARIS NIMES LYON PARIS NIMES LYON PARIS
Fichier physique STOCK95
Figure 4.7 : implmentation de l'union par un fichier logique. Les enregistrements sont reprsents dans lordre o ils apparatront travers le fichier logique LF1.
Les slections, ou les omissions, sont dfinies au niveau Slection, en dernier, aprs la cl si elle est dfinie. La slection permet de voir les enregistrements qui correspondent un certain domaine de validit. Elle est codifie avec un S en colonne 17 (exemple 4.6). Lomission, au contraire, ignore ces enregistrements. Elle est codifie avec un O en colonne 17 (exemple 4.7). En colonne FONCTION, les mots-cls classiques CMP (oprateur de comparaison), RANGE (pour un intervalle) et VALUES (pour une liste de valeurs) permettent de dfinir les domaines de validit. ALL sadresse tous les enregistrements. Les zones cites doivent obligatoirement tre dans le format du fichier logique.
R NOM FORMAT1 NOMCLI NUMCLI SOLDE TYPE NUMCLI SOLDE FONCTION PFILE (PF1)
K S
CMP(GT 0)
Exemple 4.6 : codification des slections. Les enregistrements dont le solde est positif seront retenus.
96
NOM FORMAT1 NOMCLI NUMCLI SOLDE TYPE K NUMCLI O TYPE S R
FONCTION PFILE (PF1)
RANGE(1 4) ALL
Exemple 4.7 : codification des omissions. Les enregistrements dont le type nest pas compris entre 1 et 4 seront retenus. La dernire ligne permet de voir tous les enregistrements qui ne sont pas omis.
Pour des slections/omissions simples, telles que nous les avons prsentes dans les exemples ci-dessus, la codification est aise. Si lon dsire traduire des propositions logiques complexes, avec des ET et des OU imbriqus, cela demande plus dattention. Dans une liste de slections/omissions o des S et des O sont codifis en colonne 17, chaque ligne est analyse indpendamment des autres (exemple 4.8). Ds que lenregistrement correspond un des critres, il est retenu ou omis. Tout se passe comme si des OU logique sparaient chaque ligne. Dans lexemple 4.8, les enregistrements retenus auront soit un solde positif, soit un type compris entre 1 et 4. Le ET logique est traduit par un blanc en colonne 17. Ainsi, dans lexemple 4.9 tout se passe comme si un ET sparait chaque ligne. Les enregistrements retenus ont la fois un solde positif et un type compris entre 1 et 4.
R NOM FORMAT1 NOMCLI NUMCLI SOLDE TYPE NUMCLI TYPE SOLDE FONCTION PFILE (PF1)
K S S
RANGE(1 4) CMP(GT 0)
Exemple 4.8 : codification du OU logique. Les enregistrements retenus ont le type compris entre 1 et 4 ou ont un solde positif.
S TYPE SOLDE RANGE(1 4) CMP(GT 0)
Exemple 4.9 : codification du ET logique. Les enregistrements retenus ont le type compris entre 1 et 4 et ont un solde positif (reprsentation partielle).
97
Dans le cas de propositions logiques complexes, lordre dans lequel on codifie les slections/omissions est important sur le plan des performances. En effet, il faut placer en premier les slections, ou les omissions, qui ont le plus de chance dtre ralises afin de diminuer les tests que doit raliser le systme avant de retenir, ou dliminer, un enregistrement. Dans le mme esprit, il est prfrable de prsenter les propositions logiques avec des OU, en jouant ventuellement sur les omissions plutt que sur des slections, car, dans ce cas, la dcision de garder, ou denlever, un enregistrement est prise ds quune condition est remplie. La slection dynamique, prsente ci-dessous, peut allger la maintenance du chemin daccs. Elle est considrer lors de la codification du fichier logique.
Les chemins daccs

Pour la dfinition de la cl, les mots-cls tant identiques ceux dcrits pour les fichiers physiques, nous ny reviendrons pas.
Le partage du chemin daccs

Lors de la compilation dun fichier logique, le systme vrifie sil peut rcuprer un chemin daccs dj existant. Si, par exemple, il existe dj un fichier logique avec la mme cl et pointant sur le mme fichier physique, il partagera son chemin daccs. Un seul chemin daccs sera utilis par les deux fichiers logiques. Les conomies de ressources sont claires, car une seule structure est maintenir. Ce partage est systmatique, sans que lon prcise quoi que ce soit au systme, et il nentrane aucune dpendance entre les fichiers logiques. Il est dailleurs probable que bon nombre de gestionnaires des donnes sur lAS/400 ignorent quels sont les fichiers qui sont soumis un tel partage. La commande DSPFD permet de voir si un fichier utilise le chemin daccs dun autre. Ce partage que nous venons de dcrire est implicite, cest le systme qui dcide. Le mot-cl REFACCPTH, de niveau Fichier, force le partage avec le chemin daccs dun fichier cit explicitement. Cest alors le programmeur qui dcide. Mais, dans ce cas, on est oblig de rcuprer toutes les caractristiques de ce chemin daccs. Les dfinitions de la cl et des slections/omissions sont recopies dans le nouveau fichier logique et il faut donc respecter les contraintes suivantes :
98
on ne peut dfinir de nouvelle cl. La cl est celle du fichier dont on partage le chemin daccs ; on ne peut indiquer de nouveaux critres de slection ; les zones composant la cl et cites dans les slections/omissions doivent tre prsentes dans le nouveau fichier. Par contre, toutes les zones du format du fichier physique peuvent tre cites, mme si elles ne figurent pas dans le fichier dont on partage le chemin daccs.
NOM R FMTP1 FONCTION REFACCPTH(BIB1/LF1) PFILE(PF1)
Exemple 4.10 : codification du mot-cl REFACCPTH. Ce fichier fait rfrence au chemin daccs du fichier logique LF1 dont il reprend la cl et les slections/omissions. Toutes les zones du format FMTP1, format du fichier physique PF1, seront vues.
La slection dynamique
Le chemin daccs dun fichier logique qui contient des slections/omissions et qui sappuie sur un fichier physique trs actif est sujet de frquentes modifications. Il suffit que la valeur contenue dans une zone soumise slection change pour que lenregistrement soit ajout, ou retir, du chemin daccs. Ces oprations peuvent consommer une quantit de ressources non ngligeable, ce qui est peut tre inutile si le fichier logique est rarement utilis. La slection dynamique, mise en uvre par le mot-cl de niveau Fichier DYNSLT, permet de neffectuer la slection/omission quau dernier moment, lors de louverture du fichier. Le chemin daccs contient, alors, tous les enregistrements, tris sur la cl. Il est plus gros mais il peut tre plus facilement partag, ce qui peut amliorer encore les performances. Lors de louverture du fichier logique utilisant la slection dynamique, tous les enregistrements sont lus, selon lordre de la cl, et de manire asynchrone. Sils correspondent aux critres de slection, ils sont retenus, sinon, ils sont ignors. Le programme attendra que les premiers enregistrements soient disponibles. Pendant quil les traitera, et de manire transparente, les autres enregistrements seront renvoys par le systme.
NOM R FORMAT1 NOMCLI NUMCLI SOLDE NUMCLI FONCTION DYNSLT PFILE (PF1)
99
SOLDE
CMP(LE 0)
Exemple 4.11 : codification de la slection dynamique.
La slection dynamique est conseiller pour des fichiers logiques peu utiliss pointant sur des fichiers physiques trs actifs. Elle est obligatoire pour les fichiers logiques sans cls et dans certaines configurations de fichiers logiques joints.
Les redfinitions de zones

Un fichier logique peut nous permettre de voir les zones avec des caractristiques diffrentes de celles quelles ont dans le fichier physique. Voici les principales modifications qui peuvent tre apportes : le nom de la zone peut tre chang ; une zone du fichier logique peut tre le rsultat dune concatnation de plusieurs zones du fichier physique ; une zone du fichier logique peut provenir dune extraction dune zone du fichier physique ; le type et la longueur des zones du fichier logique peuvent tre diffrents de ceux du fichier physique ; on peut utiliser des tables de translations afin de convertir des zones de type Alphanumrique.
Renommer une zone

On peut avoir besoin de renommer une zone pour deux raisons principales : soit parce que le programme la connat sous un autre nom, soit parce que le langage ne supporte pas ce type de nom. Cest le cas du RPG/400, par exemple, qui nautorise que des noms de 6 caractres de long. Cest le mot-cl RENAME qui donne un nouveau nom la zone.
La concatnation
La concatnation permet de voir le contenu de plusieurs zones au travers dune seule. Il est prconis, au niveau de la conception de la base de donnes, dclater au maximum les donnes stockes dans les fichiers physiques, afin, notamment,
100
damliorer les contrles. Cest le cas pour les dates : le jour, le mois et lanne doivent tre dans des zones distinctes. Le mot-cl CONCAT laisse voir, au travers du fichier logique, une seule zone rsultant de la juxtaposition de plusieurs zones du fichier physique.
101
Le changement de type
Tous les changements de types ne sont pas autoriss ; notamment, le passage de lAlphanumrique vers le Dcimal condens et linverse sont impossibles.
Lextraction
Lextraction permet de voir une partie seulement dune zone du fichier physique. La syntaxe du mot-cl SST est la mme quen langage de contrle :
SST(ZONE1 DEBUT LONGUEUR)
o DEBUT est la position de dbut et LONGUEUR le nombre de caractres extraire partir de la zone ZONE1. Son emploi est limit aux zones utilises en lecture seulement (I codifi en colonne Usage). Elles ne peuvent servir mettre jour le fichier physique.
La translation
Une table de translation peut permettre de voir diffremment les zones alphanumriques, chaque caractre tant ventuellement transform en un autre caractre, en fonction du contenu de la table. Ainsi, les minuscules peuvent tre automatiquement transformes en majuscules (table QSYSTRNTBL de QSYS). Son emploi est limit aux zones utilises en lecture seulement (I codifi en colonne Usage).
Exemple
R NOM FORMAT1 NOMCLI SOCIETE NUMCLI SOLDE CODEP DATE USAGE I 6 +2 0 +1 I SST(ADRESSE 1 5) CONCAT(JOUR MOIS AN) FONCTION PFILE(PF1) TRNTBL(TABLE1) RENAME(NOMSOC)
Exemple 4.12 : les principales redfinitions de zones dans les fichiers logiques. La zone NOMCLI est vue travers la table de translation TABLE1 ; NOMSOC est renomme SOCIETE ; NUMCLI, qui est de longueur 5 dont 0 dans le fichier physique, est vue avec une longueur de 6 dont 0 ; SOLDE occupe 2 positions de plus que dans le fichier physique avec
102
1 dcimale supplmentaire ; CODEP correspond aux 5 premiers caractres de ADRESSE et DATE est la concatnation de JOUR, MOIS et AN.
Lexemple 4.12 reprend ces diffrentes possibilits.
Les fichiers logiques multiformats

Les fichiers logiques multiformats permettent daccder aux enregistrements de plusieurs fichiers physiques (jusqu 32), chacun de ces fichiers tant gnralement vu au travers dun format. Le lien entre les enregistrements de ces diffrents formats est une valeur de cl.
Un exemple pour commencer

Lexemple classique pour illustrer ces fichiers est ldition dune facture. Une facture est compose dun en-tte, provenant dun enregistrement du fichier ENTETE, et de nombreuses lignes de dtail, provenant dautant denregistrements du fichier DETAIL. Tous ces enregistrements ont en commun le mme numro de facture. Un fichier logique multiformat nous permet de voir toutes les donnes relatives la facture, quelles appartiennent au fichier FACTURE ou au fichier DETAIL. Elles seront vues sous deux formats, en fonction de leur provenance. Lexemple 4.13 illustre un tel fichier logique. Dans lexemple 4.13, un programme qui lit squentiellement le fichier FACTURE verra tout dabord un enregistrement de format FMT1 correspondant len-tte de la facture 950601, puis il verra les diffrents enregistrements de format FMT2 correspondant au dtail de cette facture. Ensuite, il verra nouveau un enregistrement de format FMT1, pour une nouvelle facture...
NOM R FMT1 NUMFAC NUMCLI DATE FONCTION REF(BIB1/DICT1) R R R TEXT(Numro de facture) TEXT(Numro de client)
Exemple 4.13a - DDS du fichier ENTETE.

NOM R FMT2 NUMFAC NUMART QTE PRIXU FONCTION REF(BIB1/DICT1) R R R R
TEXT(Numro de larticle) TEXT(Quantit de larticle) TEXT(Prix unitaire de larticle)
103
Exemple 4.13b - DDS du fichier DETAIL.

NOM FMT1 NUMFAC FMT2 NUMFAC NUMART FONCTION PFILE(ENTETE) PFILE(DETAIL)
R K R K K
Exemple 4.13c - DDS du fichier logique FACTURE. Pour simplifier, toutes les zones des formats FMT1 et FMT2 sont ramenes (FMT1 et FMT2 sont respectivement les formats de ENTETE et DETAIL).
FICHIER NUMFAC 950602 950601 ENTETE NUMCLI 12345 67890 FICHIER NUMFAC 950602 950601 950602 950601 950601 DETAIL NUMART 20 25 05 20 30
DATE 010695 020695
QTE 1 1 8 2 5
PRIXU 10 5 25 10 2
Exemple 4.13d - contenu des fichiers ENTETE et DETAIL.

FORMAT NUMFAC 950601 FMT1 NUMCLI 67890 FORMAT NUMFAC 950601 950601 950601 950602 12345 010695 950602 950602 05 20 8 1 25 10 FMT2 NUMART 20 25 30
DATE 020695
QTE 2 1 5
PRIXU 10 5 2
Exemple 4.13e - le contenu du fichier FACTURE tel quil est vu par un programme.
Le programme doit videmment tenir compte de cette alternance de formats. Les exemples 4.13f et 4.13g prsentent deux logiques de programmation. Dans le premier cas, les enregistrements tant lus squentiellement, toutes les factures sont traites. Un indicateur est associ chaque format (dans la spcification I). Lors de la lecture dun enregistrement, lindicateur qui correspond au format de cet enregistrement est mis en fonction. Le programme doit donc tester ces indicateurs pour savoir quand il vient de lire les donnes dune nouvelle facture, ou quand il traite une ligne de dtail. Lexemple 4.13g prsente un accs sur cl. Le programme accde lenregistrement de format FMT1 ayant pour valeur de cl le numro de la facture
104
slectionn (code opration CHAIN). Il lit ensuite squentiellement tous les enregistrements de format FMT2 qui correspondent cette facture (code opration READE).
105
FFACTURE IF E FIMPFAC O E * IFMT1 51 IFMT2 52 C* C C *IN90 C *IN51 C C C C C C C C C
DISK PRINTER
READ FACTURE DOWEQ*OFF IFEQ *ON WRITEFMTENT MOVE *OFF ELSE WRITEFMTDET MOVE *OFF ENDIF READ FACTURE ENDDO MOVE *ON
90
*IN51
*IN52 90 *INLR
Exemple 4.13f - programme RPG/400 traitant en squentiel le fichier logique FACTURE pour une dition. Lindicateur 51 est associ au format FMT1 et 52 FMT2. Tous les enregistrements sont lus en squentiel : si un enregistrement correspondant au format FMT1 est lu, cest alors le format FMTENT qui est crit, sinon cest FMTDET, correspondant une ligne de dtail, qui est envoy vers le fichier spoule.
FFACTURE IF E K DISK FIMPFAC O E PRINTER C* C *ENTRY PLIST C PARM NUMFAC C* C NUMFAC CHAINFMT1 90 C *IN90 IFEQ *OFF C* C*ECRITURE DE L'ENTETE DE LA FACTURE C WRITEFMTENT C* C*BOUCLE D'ECRITURE DES ENREGISTREMENT DE DETAIL C NUMFAC READEFMT2 C *IN91 DOWEQ*OFF C WRITEFMTDET C NUMFAC READEFMT2 C ENDDO C ENDIF C*TRAITEMENT DE FIN C MOVE *ON *INLR
91
91
Exemple 4.13g - programme RPG/400 traitant en accs slectif le fichier logique FACTURE pour une dition. Le numro de la facture traiter est reu en paramtre. Une recherche sur cl (CHAIN) est effectue sur le format FMT1 (pour ramener len-tte), puis une lecture squentielle est opre sur FMT2 (READE), tant quil y a correspondance de la cl (pour les
106
enregistrements de dtail). Les formats FMTENT et FMTDET appartiennent au fichier dimpression IMPFAC.
La thorie
Dans les DDS du fichier logique multiformat, on doit dcrire tous les formats en spcifiant, chaque fois, le nom du fichier physique, lensemble des zones qui sont vus au travers de ce format, et la cl. Lordre dans lequel les formats sont dcrits est important. Il existe, en effet, une hirarchie dans les cls. La cl du premier format dcrit doit se retrouver dans la premire partie de la cl du second (cest elle qui fait le lien entre les enregistrements), la cl du troisime contenant aussi la cl du second et ainsi de suite pour tous les formats (exemple 4.14).
R NOM FMTLF1 ZONEA ZONEB ZONEA FMTLF2 ZONEA ZONEC ZONED ZONEA ZONEC FMTLF3 ZONEA ZONEC ZONEE ZONEA ZONEC ZONEE FONCTION PFILE(PF1)
K R
PFILE(PF2)
K K R
PFILE(PF3)
K K K
Exemple 4.14a : DDS dun fichier logique multiformat.

NOM FMTLF3 ZONEA ZONEE ZONEA *NONE ZONEE FONCTION PFILE(PF3)
K K K
Exemple 4.14b : DDS dun fichier logique multiformat avec une partie de la cl manquante. Par rapport lexemple 4.14a, ZONEC nest pas prsente dans le fichier PF3, elle ne peut donc pas figurer dans la cl, mais son emplacement doit tre conserv par *NONE (reprsentation partielle).
107
Parfois, un fichier physique vu en troisime position, ou mme plus loin, ne contient pas toutes les zones qui devraient composer la cl du format correspondant. Ces zones manquantes doivent alors tre remplaces par *NONE dans la description de la cl (exemple 4.14b). Pour revenir notre facturation, on peut admettre quun fichier REMISE contient les diffrents types de rduction appliquer une facture. Ces rductions sappliquent sur le total de la facture et ne dpendent pas des articles (par exemple, 3% de remise ngocies avec le commercial, plus 2 % pour paiement comptant, plus 1% pour commande dpassant 50 000F). Lexemple 4.15 reprend celui que nous avons vu prcdemment (4.13) et tient compte de ce fichier REMISE.
NOM R FMT3 NUMFAC POURC LIBEL CODE FONCTION REF(BIB1/DICT1) R R R R
TEXT(Pourcentage de remise) TEXT(Libell de la remise) TEXT(Code de la remise)
Exemple 4.15a : DDS du fichier REMISE.

R K R K K R K K K NOM FMT1 NUMFAC FMT2 NUMFAC NUMART FMT3 NUMFAC *NONE POURC FONCTION PFILE(ENTETE) PFILE(DETAIL)
PFILE(REMISE)
Exemple 4.15b : DDS du fichier FACTURE intgrant les remises. NUMART nest pas prsent dans le fichier REMISE, il est donc remplac par *NONE dans la cl du format FMT3.
La mise jour
La mise jour travers ces fichiers logiques mrite une attention particulire. Dans le cas dajout, il faut prciser quel fichier physique est destin cet enregistrement. La premire possibilit consiste donner le nom du format concern en regard de lordre dcriture. Il ny a aucune ambigut possible car le format est associ un seul fichier physique. La seconde possibilit consiste citer le nom du fichier logique au niveau du WRITE. Un programme, dit slecteur de format, va dfinir le fichier physique qui doit recevoir les donnes. Ce programme slecteur de format est associ au fichier logique. Il est codifier avec
108
les rgles que nous allons dtailler et doit tre cit au niveau du paramtre FMTSLR de la commande CRTLF. Il est trs utile quand on a des donnes dans un fichier o les enregistrements sont sous plusieurs formats et que lon dsire les organiser en respectant lesprit de lAS/400 et plus gnralement des bases de donnes relationnelles, cest--dire un fichier physique par format. Cest souvent le cas pour les fichiers provenant de lIBM/36 que lon souhaite migrer en natif. Un premier programme lit le fichier dorigine et crit lenregistrement dans le fichier logique multiformat. Le programme slecteur de format est alors automatiquement lanc et reoit en paramtre lenregistrement crire. Il renvoie le nom du format choisi dans un autre paramtre. La longueur du premier paramtre doit correspondre la longueur du plus grand enregistrement qui peut tre reu, le second doit occuper 10 caractres. Gnralement, et toujours sur lIBM/36, la premire lettre de lenregistrement indique quel est son format : un E pour en-tte, un D pour dtail... Lexemple 4.16 dcrit un programme slecteur de format pour ce type de fichier.
C *ENTRY PLIST C PARM ENREG 60 C* 60 EST LA LONGUEUR DU PLUS GRAND ENREGISTREMENT C PARM FORMAT 10 C* PARAMETRE POUR RETOURNER LE NOM DU FORMAT CHOISI C* C MOVELENREG PREM 1 C PREM IFEQ 'E' C MOVEL'ENTETE' FORMAT C ELSE C MOVEL'DETAIL' FORMAT C ENDIF C RETRN
Exemple 4.16 : programme slecteur de format. Le premier caractre de lenregistrement trait est plac dans la variable PREM. Ensuite, si PREM=E alors FORMAT prend pour valeur ENTETE, sinon il prend pour valeur DETAIL.
Conclusions
Les fichiers logiques multiformats apportent certains avantages au niveau du dveloppement : il ny a quun seul fichier dclarer et utiliser. Par contre, le programme doit grer les multiples formats, en lecture aussi bien quen criture. Il reste remarquer que, dans certains cas, lutilisation de ces fichiers est moins performante que lemploi de plusieurs fichiers (logiques ou physiques), avec des accs sur cl pour slectionner les diffrents enregistrements.
Conclusions sur les fichiers logiques non joints
109
Les fichiers logiques non-joints apportent une grande souplesse la base de donnes de lOS/400. Ils permettent la consultation et la mise jour denregistrements. Ils sont employs de la mme manire que les fichiers physiques, seule la ralisation de programmes bass sur des fichiers logiques multiformats tant plus dlicate. Utiliss bon escient, ils peuvent procurer des gains substantiels en termes de dveloppement, de scurit et de performance.
Les fichiers logiques joints

Principes
Les fichiers logiques joints permettent de voir, sous un seul format, des donnes qui proviennent de plusieurs fichiers. Ils correspondent la jointure qui est un des principes de base du modle relationnel. Pour bien illustrer cette jointure prenons un exemple simple : un fichier ENTETE contient le numro de la facture, la date et le code du client. Le fichier CLIENT contient, lui, le code, le nom et ladresse du client (figure 4.8). Pour diter la facture, il faut toutes ces informations. En programmation classique, on extrait NUMCLI partir dun enregistrement du fichier ENTETE, puis on effectue une recherche (indexe si possible) dans le fichier CLIENT pour extraire les informations relatives ce client. On peut alors gnrer len-tte de la facture. Un fichier logique joint nous vite de faire cette recherche puisquil met en concordance les enregistrements des deux fichiers en fonction du contenu dune (ou de plusieurs) zone(s). Le programme travaille directement sur ce fichier et a toutes les informations ncessaires sa disposition. En une seule lecture, il a tout ce qui concerne une facture. Lexemple 4.17 prsente les DDS de ce fichier.
La codification
La codification des fichiers logiques joints est assez simple. Elle est base sur quelques mots-cls que nous allons dtailler, en commenant par la jointure de deux fichiers.
110
FACTURE
NUMFAC 950602 950601 950603
NUMCLI 12345 67890 12345
NOMCLI DEVILLE PAGNOL DEVILLE
ADRESSE PARIS NIMES PARIS
DATE 010695 020695 030695
ENTETE
NUMFAC 950602 950601 950603 NUMCLI 12345 67890 12345 DATE 010695 020695 030695 NUMCLI 12345 67890 99999 NOMCLI DEVILLE PAGNOL MOULIN
CLIENT
ADRESSE PARIS NIMES LYON
Figure 4.8 : prsentation dun fichier logique joint.
Jointure de deux fichiers

JFILE
permet de lister les fichiers joindre, dans lordre o ils sont joints. Il peut y en avoir jusqu trente deux.
Les fichiers sont joints deux deux. JOIN permet de dfinir les couples et JFLD dcrit les zones qui servent tablir la correspondance. Il y a autant de JOIN et de JFLD que de couples de fichiers joindre. JOIN est toujours prcd dun J en colonne 17. Enfin, les couples cits dans ce mot-cl doivent ltre dans lordre o ils apparaissent dans JFILE. Lexemple 4.17 prsente ces mots-cls.
R J NOM FMT1 FONCTION JFILE(ENTETE CLIENT) JOIN(ENTETE CLIENT) JFLD(NUMCLI NUMCLI) JREF(ENTETE)
NUMFAC NUMCLI NOMCLI ADRESSE DATE NUMFAC
Exemple 4.17a : les DDS dun fichier logique joint. Il joint les fichiers ENTETE et CLIENT sur la zone NUMCLI. Les enregistrements apparaissent tris sur le numro de facture.
NUMFAC 950602 950601 950603 950605 ENTETE NUMCLI 12345 67890 12345 12345 DATE 010695 020695 030695 070695 NUMCLI 12345 67890 CLIENT NOMCLI DEVILLE PAGNOL ADRESSE PARIS NIMES
111
950606 950604
99999 67890
080695 050695
Exemple 4.17b : contenu des fichiers ENTETE et CLIENT.

NUMFAC 950601 950602 950603 950604 950605 NUMCLI 67890 12345 12345 67890 12345 NOMCLI PAGNOL DEVILLE DEVILLE PAGNOL DEVILLE ADRESSE NIMES PARIS PARIS NIMES PARIS DATE 020695 010695 030695 050695 070695
Exemple 4.17c : le contenu du fichier logique joint tel quil est vu par un programme. Lenregistrement correspondant la facture 950606 napparait pas car le numro de client na pas de correspondance dans le fichier CLIENT.
Certaines zones de deux fichiers physiques joints peuvent avoir le mme nom. Le mot-cl JREF permet de lever toute ambigut sur lorigine des donnes de cette zone. Pour NUMCLI de lexemple 4.17, cest la zone du fichier ENTETE qui est retenue. Si la zone de jonction doit rester cache, il faut codifier un N en colonne Usage. Elle napparatra pas dans le format.
Jointure de trois fichiers

En admettant que le fichier CLIENT contienne le code du commercial (zone NUMCOM), on peut imaginer un fichier logique joignant trois fichiers physiques (exemple 4.18). Le but est davoir, dans un seul enregistrement, toutes les informations sur len-tte de la facture, sur le client qui est destin cette facture et sur le commercial charg de ce client. La gnration de ltat imprimer est trs rapide puisquil sagit deffectuer une seule lecture pour avoir toutes les donnes. Pour allger lcriture, le nom des fichiers physiques peut tre remplac par un nombre qui correspond la position du fichier dans le mot-cl JFILE (exemple 4.19).
NOM R FMT1 J J NUMFAC NUMCLI NOMCLI ADRESSE FONCTION JFILE(ENTETE CLIENT VENDEUR) JOIN(ENTETE CLIENT) JFLD(NUMCLI NUMCLI) JOIN(CLIENT VENDEUR) JFLD(NUMCOM NUMCOM) JREF(ENTETE)
112
DATE NUMCOM NOMCOM K NUMFAC
JREF(VENDEUR)
Exemple 4.18 : les DDS dun fichier logique joint pointant sur trois fichiers physiques.
Ordre des enregistrements

La cl est constitue de zones qui sont obligatoirement dans le premier fichier cit. Si des enregistrements ont mme valeur de cl, ils peuvent alors tre tris sur une zone figurant ventuellement dans un autre fichier, et spcifie au niveau du motcl JDUPSEQ (exemple 4.19). Pour avoir un tri dcroissant, il aurait fallu prciser JDUPSEQ(NOMCLI *DESCEND).
NOM R FMT1 J NUMFAC NUMCLI NOMCLI ADRESSE DATE K DATE FONCTION JFILE(ENTETE CLIENT) JOIN(1 2) JFLD(NUMCLI NUMCLI) JDUPSEQ(NOMCLI) JREF(1)
Exemple 4.19 : codification du mot-cl JDUPSEQ. Si deux enregistrements ont mme valeur de date, ils apparatront tris sur le nom du client.
Enregistrements sans correspondance

Dans les exemples que nous avons vu jusqu prsent, seuls les enregistrements du fichier primaire qui avaient une correspondance dans le fichier secondaire taient ramens. La facture 950606 de lexemple 4.17 dont le contenu de la zone NUMCLI na pas dquivalence dans le fichier CLIENT, na pas t retenue. Pour voir aussi les enregistrements qui ne sont pas en concordance, il faut codifier JDFTVAL au niveau Fichier. Les valeurs par dfaut sont alors renvoyes pour les zones correspondant au deuxime fichier. DYNSLT doit figurer avec ce mot-cl.
NOM FONCTION
113
R J
FMT1
DYNSLT JDFTVAL JFILE(ENTETE CLIENT) JOIN(ENTETE CLIENT) JFLD(NUMCLI NUMCLI) JREF(ENTETE)
NUMFAC NUMCLI NOMCLI ADRESSE DATE NUMFAC
Exemple 4.20a : les DDS de lexemple 4.17 avec le mot-cl JDFTVAL.
Lexemple 4.20 reprend la codification et le rsultat de lexemple 4.17, en intgrant JDFTVAL. Il faut remarquer que, si JREF(CLIENT) avait t codifi en regard de NUMCLI, alors la valeur par dfaut aurait t renvoye pour cette zone, puisque sa valeur serait prise dans le deuxime fichier.
NUMFAC 950601 950602 950603 950604 950605 950606
NUMCLI 67890 12345 12345 67890 12345 99999
NOMCLI PAGNOL DEVILLE DEVILLE PAGNOL DEVILLE
ADRESSE NIMES PARIS PARIS NIMES PARIS
DATE 020695 010695 030695 050695 070695 080695
Exemple 4.20b - le contenu du fichier logique joint tel quil est vu par un programme. Lenregistrement correspondant la facture 950606 apparait avec les valeurs par dfaut pour les zones NOMCLI et ADRESSE.
La jointure dun fichier sur lui-mme

Le traitement darborescence nous amne oprer une jointure dun fichier sur luimme. Cest le cas classique du fichier EMPLOYE qui contient le code du suprieur hirarchique, qui est lui aussi un employ avec un chef. Les nomenclatures (liste darticles composant un article) en sont un autre exemple. La mise en uvre est simple (exemple 4.21).
R J NOM FMT1 FONCTION JFILE(EMPLOYE EMPLOYE) JOIN(1 2) JFLD(NUMSUP NUMEMP) JREF(1) JREF(1) JREF(1)
NUMEMP NOMEMP NUMSUP
114
NOMSUP K NUMEMP
RENAME(NOMEMP) JREF(2)
Exemple 4.21 : la jointure dun fichier sur lui-mme : cas du fichier EMPLOYE. NUMEMP et NOMEMP prcisent le numro et le nom de lemploy. NOMSUP correspond au nom du suprieur. On est oblig de renommer cette zone car NOMEMP sert dj pour le nom de lemploy.
La jointure sur plusieurs zones

Si deux fichiers physiques sont joints sur plusieurs zones, on doit indiquer autant de JFLD quil y a de couple de zones comparer (exemple 4.22). Pour quil y ait concordance, il faut que toutes les galits soient obtenues.
Remarques
Les restrictions ci-dessous sappliquent aux fichiers logiques joints : ils ne peuvent servir mettre jour les donnes des fichiers physiques ; leur contenu ne peut tre visualis par DFU ; la cl doit appartenir au premier fichier cit ; un seul format peut tre dfini. Il ne peut tre celui dun fichier dj existant (le partage de format est impossible).
R J NOM FMT1 FONCTION JFILE(FICHA FICHB) JOIN(1 2) JFLD(ZONE1A ZONE1B) JFLD(ZONE2A ZONE2B)
ZONE1A ZONE1B ZONE2A ZONE2B ZONE1A
Exemple 4.22 : jointure de 2 fichiers sur plusieurs zones. ZONE1A et ZONE2A appartiennent FICHA, les autres zones FICHB. Lors de la jointure, le contenu de ZONE1A sera compar celui de ZONE1B et celui de ZONE2A celui de ZONE2B.
Les zones participant aux slections/omissions peuvent provenir de nimporte quel fichier, condition quelles soient cites dans le format. Le mot-cl DYNSLT est parfois obligatoire.
115
Pour chaque enregistrement du fichier primaire, on voit tous les enregistrements du fichier secondaire qui sont en concordance (exemple 4.23).
NUMFAC 950602 950601 950603 ENTETE NUMCLI 12345 67890 12345 DATE 010695 020695 030695 NUMCLI 12345 67890 12345 CLIENT NOMCLI DEVILLE PAGNOL DOUBLE ADRESSE PARIS NIMES LYON
Exemple 4.23a : contenu des fichiers ENTETE et CLIENT.

NUMFAC 950601 950602 950602 950603 950603 NUMCLI 67890 12345 12345 12345 12345 NOMCLI PAGNOL DEVILLE DOUBLE DEVILLE DOUBLE ADRESSE NIMES PARIS LYON PARIS LYON DATE 020695 010695 010695 030695 030695
Exemple 4.23b : le contenu du fichier logique joint tel quil est vu par un programme. Les DDS correspondent lexemple 4.20. Remarquer que les factures avec 12345 comme numro de client donnent 2 enregistrements, lun pour le client DEVILLE, lautre pour DOUBLE.
Pour rsumer les contraintes sur lutilisation du mot-cl DYNSLT, il faut noter quil doit tre employ dans les cas suivants : si aucune cl nest prcise ; si le mot-cl JDFTVAL est codifi ; si, dune manire gnrale, les zones participant aux slections/omissions sont dans des fichiers diffrents. Sur le plan des performances, il est important de noter quil faut : chaque fois que cela est possible, essayer de citer en premier le fichier qui a le plus petit nombre denregistrements ; envisager lopportunit dutiliser DYNSLT ; tenter de codifier la cl afin de partager un chemin daccs existant ; penser que le systme a besoin dun chemin daccs pour la deuxime zone cite en regard de JFLD (la plus droite). Sil nexiste pas, ce chemin daccs est cr.
Conclusions sur les fichiers logiques joints
116
Les fichiers logiques joints sont indispensables pour ceux qui dsirent utiliser pleinement la base de donnes relationnelle de lAS/400. Ils permettent davoir dun cot une bonne organisation des donnes, sans redondance, et de lautre des programmes simples qui grent un minimum de fichiers. Ils sont cependant limits la lecture des enregistrements, la mise jour leur tant interdite. Il faut noter que la jointure peut tre ralise laide de certains utilitaires (Query, PCS/400 et CA/400...) et par la commande OPNQRYF. Les concordances peuvent mme tre tablies, non plus en fonction de lgalit des zones, mais en fonction dun oprateur logique (plus grand que, plus petit que...).
Les principaux mots-cls des DDS des fichiers logiques

Les DDS de niveau Fichier
ALTSEQ DYNSLT JDFTVAL
dfinit une table de tri pour les zones cls ; utilise la slection dynamique des enregistrements ; prcise que les enregistrements nayant pas de correspondances sont vus (fichiers logiques joints seulement) ; indique avec quel fichier doit se faire le partage des chemins daccs (fichiers logiques non joints seulement) ; signifie que deux enregistrements ne pourront avoir une mme valeur de cl.
REFACCPTH
UNIQUE
Les enregistrements ayant une mme valeur de cl apparatront tris dans l'ordre suivant :
FCFO FIFO LIFO
lenregistrement le premier modifi est renvoy dabord ; le premier crit dans le fichier est renvoy dabord (valeur par dfaut) ; le dernier crit dans le fichier est renvoy dabord.
Les DDS de niveau Format

FORMAT
ramne le format d'un fichier physique existant
117
JDUPSEQ
JFILE JFLD
JOIN PFILE
TEXT
(fichiers logiques non joints seulement) ; trie les enregistrements valeur de cl duplique, en fonction dune zone dun fichier secondaire (fichiers logiques joints seulement) ; liste des fichiers joindre (fichiers logiques joints seulement) ; dfinit un couple de zones dont on va comparer les valeurs pour effectuer la jointure (fichiers logiques joints seulement) ; dfinit un couple de fichiers joindre (fichiers logiques joints seulement) ; dfinit le (ou les) fichier(s) physique(s) vu(s) par le fichier logique (fichiers logiques non joints seulement) ; indique les commentaires.
Les DDS de niveau Zone

ALIAS CHECK CHKMSGID COLHDG COMP ou CMP CONCAT DATFMT DATSEP EDTCDE EDTWRD FLTPCN JREF RANGE REFSHIFT TEXT TIMFMT TIMSEP
dfinit un nom de substitution pour une zone ( destination des programmes) ; prcise les caractristiques de la saisie ; identifie le message d'erreur renvoyer en cas de saisie d'une valeur hors du domaine de validit ; dfinit des en-ttes de colonne (jusqu' trois) ; permet la comparaison par rapport une valeur ; provoque la concatnation des zones du fichier physique ; dfinit le format d'une zone de type Date ; dfinit le sparateur pour une zone de type Date ; donne la dfinition du code d'dition ; donne la dfinition du mot d'dition ; donne la prcision des zones de type virgule flottante ; prcise lorigine dune zone prsente dans plusieurs fichiers (fichiers logiques joints seulement) ; dfinit un domaine de validit ; conditionne le clavier ; prcise les commentaires ; dfinit le format d'une zone de type Heure ; dfinit le sparateur pour une zone de type Heure ;
118
VALUES VARLEN
donne la liste des valeurs admises ; dfinit une zone de longueur variable.
Les DDS de niveau Cl

Les enregistrements apparaissent tris :
ABSVAL DESCEND DIGIT NOALTSEQ SIGNED UNSIGNED ZONE
sur la valeur absolue des zones ; dans l'ordre dcroissant ; selon la partie numrique de la reprsentation hexadcimale ; en inhibant, pour cette zone cl, la table de tri spcifie dans le mot-cl altseq ; en tenant compte du signe (la valeur par dfaut du tri classique) ; en ignorant le signe ; c'est la reprsentation hexadcimale qui est utilise pour effectuer le tri ; selon la partie alphabtique de la reprsentation hexadcimale.
Les DDS de niveau Slection

ALL CMP ou COMP RANGE VALUES
sapplique tous les enregistrements ; est un oprateur de comparaison ; dfinit un intervalle de valeurs ; liste les valeurs permises.
La commande de cration des fichiers logiques

La commande CRTLF permet de crer un fichier logique partir des DDS. De nombreux paramtres tant identiques ceux dfinis pour la commande CRTPF, nous ny reviendrons pas. Nous ne prsenterons ici que les paramtres propres aux fichiers logiques, regroups en thmes. Un rcapitulatif de tous les mots-cls est prsent la fin de ce chapitre.
Les membres
Comme pour les fichiers physiques, on ne peut ajouter quun seul membre lors de la cration dun fichier logique. Le paramtre MBR prcise le nom de ce membre, sil existe. Le paramtre DTAMBRS dfinit le, ou les, membre(s) du, ou des,
119
fichier(s) physique(s) vu(s) par le fichier logique. Les rapports entre les membres des fichiers physiques et ceux du fichier logique peuvant tre relativement complexes, ils feront lobjet dun chapitre particulier.
Le programme slecteur de format

Pour les fichiers logiques multiformats, un programme peut tre utilis pour dfinir, par lintermdiaire du format, quel est le fichier qui doit recevoir un nouvel enregistrement. Le paramtre FMTSLR permet de prciser le nom et la bibliothque de ce programme. Ce sujet dj t trait dans la section Les fichiers logiques multiformats - La mise jour du prsent chapitre.
Estimation de la taille d'un fichier logique

Nous pouvons estimer la taille d'un fichier logique l'aide de la formule suivante :
TAILLE
= ((nombre de membres) 2560) + 1024
Il faut ajouter cela l'espace occup par le chemin d'accs, pour chacun des membres, estim par la formule suivante :
(nombre d'enregistrements vus (longueur de la cl + 8) 0,8 1,85) + 4096
Comme pour les fichiers physiques, 0,8 est un cfficient qui correspond une compression moyenne. 1,85 est le facteur qui permet de prendre en compte la place rserve par le systme pour l'extension du chemin d'accs. La commande DSPFD permet de visualiser la place rellement occupe par un fichier physique, ou logique. Pour tre prcis il faut rajouter que le systme maintient des structures qui occupent aussi un certain espace disque. Nous ne les dtaillerons pas car elles peuvent paratre comme ngligeables.
Les principaux paramtres de la commande CRTLF

Voici la liste des principaux mots-cls de la commandes CRTLF, et de CHGLF, rangs par ordre alphabtique :
AUT DTAMBRS
dfinit les droits publics ; prcise les noms des diffrents membres des fichiers
120
FILE FILETYPE FLAG FMTSLR FRCACCPTH FRCRATIO GENLVL LVLCHK MAINT MAXMBR MBR OPTION RECOVER SHARE SRCFILE SRCMBR SYSTEM TEXT UNIT WAITFILE WAITRCD
physiques vus par le membre du fichier logique ; est le nom du fichier crer ; spcifie si le fichier cr est destin contenir des donnes ou des sources ; indique le niveau de gravit minimum des messages pour quils soient placs dans le listing de compilation ; donne le nom du programme slecteur de format ; prcise quand le chemin daccs est rellement crit sur disque ; indique quand le systme doit crire rellement les enregistrements sur disque ; indique le niveau de gravit partir duquel le fichier ne sera pas cr ; prcise si lidentificateur de format doit tre compar celui du programme ; indique, si le fichier a une cl, comment est maintenu le chemin daccs ; prcise le nombre maximum de membres que pourra contenir le fichier ; donne le nom du membre ajout lors de la cration du fichier physique ; prcise le type dtat qui est gnr lors de la compilation ; prcise le mode de reconstruction du chemin daccs aprs incident ; dfinit sil peut y avoir partage de lODP ; est le nom du fichier source ; est le nom du membre source ; spcifie le nom du systme sur lequel est cr le fichier ; correspond au commentaire ; indique lunit sur laquelle le systme doit tenter de placer le fichier et ses chemins daccs ; prcise le dlai, en secondes, pendant lequel un programme pourra attendre que fichier soit libr ; prcise le dlai, en secondes, pendant lequel un programme pourra attendre quun enregistrement soit libr.
Les membres
Supposons, dans un premier temps, quun fichier logique voit un seul fichier physique. Si ce dernier possde un seul membre, alors le fichier logique naura, lui
121
aussi, quun seul membre. Le schma se complique un peu si le fichier physique a plusieurs membres. Un membre du fichier logique peut voir un membre en particulier, une srie de membres et mme tous les membres du fichier physique (figure 4.9). Cest le paramtre DTAMBRS de la commande CRTLF ou de ADDLFM, qui permet deffectuer ces affectations.
STAT
STOCK
PARIS NIMES SUD FRANCE
PARIS
NIMES LYON
Figure 4.9 : fichier logique pointant sur un fichier physique multimembre. Le fichier logique STAT est utilis pour tablir des statistiques sur les stocks. Le membre PARIS voit les enregistrements du membre PARIS du fichier physique ; NIMES voit le membre NIMES ; SUD voit le membre NIMES et le membre LYON ; enfin FRANCE voit tous les enregistrements de tous les membres. Selon le membre du fichier logique slectionn, le programme de statistique traitera un stock particulier, ou le sud, ou toute la France.
Les choses peuvent se compliquer souhait quand on sait quun fichier logique peut voir plusieurs fichiers physiques. Chacun des membres du fichier logique peut voir, tout ou partie, des membres de chacun des fichiers physiques. Il faut dailleurs remarquer que le paramtre DTAMBRS possde deux lignes autorisant la saisie dautres valeurs (avec un +). Lune est pour saisir les diffrents fichiers physiques, lautre pour les diffrents membres de chacun de ces fichiers physiques. La figure 4.10 prsente un fichier logique sappuyant sur deux fichiers physiques.
122
ANNEE
STAT
STOCK
1994 1995
PARIS A NIMES B C D LYON
1996
Figure 4.10 : fichier logique pointant sur des fichiers physiques multimembres. Le fichier logique STAT voit les enregistrements des fichiers physiques STOCK et ANNEE.
Au maximum trente deux membres de fichiers physiques peuvent tre vus par un membre dun fichier logique. A la cration dun fichier logique, un seul membre peut tre dfini. Dautres pourront tre ajouts, par la suite, avec la commande ADDLFM. En conclusion :
Chaque membre dun fichier logique peut tre dfini sur un ou plusieurs membres de chacun des fichiers physiques sur lequel il pointe.
123
Les chemins daccs

Un fichier logique est constitu dune partie descriptive, comme tous les objets de lOS/400, et dun chemin daccs par membre. Ces derniers constituent donc la partie fondamentale de ces fichiers. Nous allons voir comment les utiliser efficacement.
Performances
Dune manire gnrale, les chemins daccs sont utiliss pour diminuer le temps de traitement des donnes dont on connat la valeur (cette valeur tant considre comme la cl). Ils peuvent tre crs en dfinissant une cl dans un fichier physique ou dans un fichier logique. Pour certaines oprations et sils nexistent pas, le systme est amen crer ses propres chemins daccs de manire permanente ou temporaire. Il est donc important de bien comprendre les mcanismes mis en uvre par lOS/400 afin danticiper ses besoins en crant, au pralable, les chemins daccs qui lui seront utiles. Les temps de rponses seront alors bien meilleurs. Voici quelques fonctions du systme qui utilisent ces structures : SQL Le produit SQL utilise au maximum les chemins daccs. Son optimiseur cherche systmatiquement sil en existe un qui pourrait lui convenir ; Le contrle dintgrit rfrentielle Le contrle dintgrit rfrentielle dfinit un lien, entre un fichier parent et un fichier dpendant, qui sappuie sur un chemin daccs. Sil nexiste pas, il est automatiquement cr. Il nest pas visible, mais le systme le gre compltement (partage possible, sauvegarde automatique avec le fichier physique) ; La commande OPNQRYF Si les critres de slection le permettent, la commande OPNQRYF utilise les chemins daccs existants ce qui peut nettement amliorer ses performances.
Les limites
On ne peut augmenter indfiniment le nombre de chemins daccs sur un systme.
124
125
Voici quelques-uns des effets nfastes lis leur prolifration : la maintenance, cest--dire le temps que passe le systme mettre jour les chemins d'accs, est extrmement coteuse en ressources (CPU, entres/sorties disque, mmoire principale...). Nous avons vu quelques mots-cls qui permettent de limiter cette consommation, mais laccroissement exagr du nombre des chemins d'accs est un facteur dgradant pour les performances ; en cas darrt anormal du systme, la reconstruction des chemins d'accs qui accompagne lIPL suivant peut prendre un temps considrable (plusieurs heures pour de gros fichiers). La phase de dmarrage du systme sera dautant plus longue quil y a de chemins d'accs reconstruire. Toutefois, la fonction SMAPP, que nous dtaillerons avec la journalisation des fichiers logiques, peut limiter cette phase ; loptimiseur (SQL, OPNQRYF...) peut devenir inefficace car sil ne trouve pas rapidement un bon chemin d'accs, il peut abandonner la recherche avant davoir examin toutes ces structures. Il est donc important de limiter le nombre de fichiers logiques au strict minimum et de dtruire ceux qui sont devenus inutiles.
La reconstruction
La reconstruction dun chemin d'accs a lieu quand il nest plus en concordance avec le(s) fichier(s) physique(s). Lvnement qui a gnr cette discordance est gnralement un arrt anormal du systme. Le paramtre RECOVER des commandes CRTPF, CRTLF, CHGPF et CHGLF prcise quand le chemin d'accs associ un fichier est reconstruit aprs un arrt anormal du systme (pendant ou aprs lIPL, ou louverture du fichier). Le temps de reconstruction dun chemin d'accs peut tre optimis en fonction des considrations suivantes : plus la cl est longue, plus important sera le temps de reconstruction ; la dure de cette opration dpend directement du nombre denregistrements des fichiers traiter ; la taille du pool de mmoire dans lequel seffectue le travail de reconstruction influe notablement sur les performances ;
126
la rapidit des disques est un facteur essentiel car tous les enregistrements doivent tre lus lors dune reconstruction ; mme lordre des enregistrements dans le fichier peut influer favorablement. Pour prvenir la reconstruction, qui est dans tous les cas coteuse en terme de ressources, il est recommand de journaliser les chemins d'accs ou dutiliser la fonction SMAPP. Le systme sappuie sur les informations du journal pour remettre trs rapidement en tat le chemin d'accs. Une autre solution, plus radicale, consiste restaurer le fichier physique et ses chemins d'accs qui auront t sauvegards au pralable.
La sauvegarde
Les commandes SAVOBJ, SAVCHGOBJ et SAVLIB permettent de sauvegarder les chemins d'accs associs un fichier physique.
La gestion des fichiers logiques

La dfinition
Les caractristiques du fichier logique sont dfinies sa cration par la commande CRTLF, mais elles peuvent tre modifies par la suite laide de la commande CHGLF. Les modifications ainsi apportes sont permanentes, et valables pour tous les utilisateurs. La substitution, par la commande OVRDBF, permet de modifier les caractristiques dun fichier pour le travail en cours seulement. Le chapitre 7 traite ce sujet pour tous les types de fichier.
La destruction
Un fichier, quel quil soit, et condition davoir les droits suffisants, peut tre dtruit par la commande DLTF. Il est alors irrcuprable. RMVM enlve un membre, dtruisant ainsi les enregistrements quil contient. La structure du fichier est conserve car sa partie descriptive nest pas touche. On prfrera cette commande DLTF chaque fois quil sagira de dtruire un fichier pour le recrer par la suite. Enlever un membre est beaucoup plus rapide que la destruction complte dun fichier et, surtout, ajouter un membre un fichier existant nest rien par rapport la cration dun nouveau fichier.
La visualisation
127
Les caractristiques gnrales dun fichier sont visualisables (ou mme imprimables) par la commande DSPFD. On peut ainsi connatre toutes les valeurs dfinies pour les paramtres de la commande CRTLF ou ventuellement de CHGLF. DSPFFD, dont la syntaxe est proche, affiche le dtail de toutes les zones qui composent le fichier. Il nexiste pas de commande quivalente DSPPFM qui affiche le contenu dun membre dun fichier physique. On devra utiliser des utilitaires tels que Query, SQL et ventuellement DFU pour les fichiers logiques non joints.
Les membres
ADDLFM permet dajouter un membre un fichier logique et RMVM de lenlever. Les caractristiques dun membre peuvent tre modifies grce CHGLFM. Il sagit essentiellement du commentaire associ ce membre et de la date dexpiration de ses enregistrements. RNMM est utiliser pour renommer un membre.
La sauvegarde
Les chemins daccs des fichiers logiques peuvent tre sauvegards. Non pas quils soient indispensables aucune donne nest perdue lors de la destruction dun fichier logique mais parce que leur reconstruction peut prendre un temps considrable. Il est donc intressant de sauvegarder les chemins daccs des fichiers logiques contenant de nombreux enregistrements afin de gagner plusieurs heures lors de leur ventuelle restauration. Cette opration doit tre effectue en mme temps que la sauvegarde des fichiers physiques concerns pour que ces objets soient cohrents entre eux lors de la restauration. Les commandes de sauvegarde et de restauration classiques sappliquent aux fichiers logiques (SAVOBJ, SAVCHGOBJ, SAVLIB, RSTOBJ, RSTLIB...).
Les utilitaires
La plupart des utilitaires traitent aussi bien, et de manire transparente, les donnes issues des fichiers physiques que celles vues par les fichiers logiques. La seule exception est peut-tre DFU qui ne peut tre utilis avec les fichiers logiques joints.
128
Conclusions sur les fichiers logiques

Les fichiers logiques sont vraiment des objets incontournables de la base de donnes de lOS/400. Du point de vue du dveloppement, ils sont garant de lindpendance entre les programmes et les donnes, et assurent une programmation simplifie car les slections denregistrements peuvent tre ralises lextrieur des programmes. Sur le plan de la scurit, ils jouent le rle de filtre ne laissant voir quune partie des donnes. Enfin, au niveau des performances, il faut contrler leur dveloppement car, en trop grand nombre, ils pourraient asphyxier le systme qui passerait son temps maintenir les chemins daccs. Une bonne utilisation des mots-cls des DDS et des paramtres de la commande CRTPF procure des temps de rponses optimaux grce une gestion efficace des chemins daccs.

ADDLFM CHGLF CHGLFM CRTLF DLTF DSPFD DSPFFD OVRDBF RMVM RNMM
ajouter un membre un fichier logique ; modifier les caractristiques dun fichier logique ; modifier les caractristiques dun membre dun fichier logique ; crer un fichier logique ; dtruire un fichier ; afficher la description dun fichier ; afficher la description des zones dun fichier ; substituer un fichier base de donnes ; enlever un membre un fichier ; renommer un membre.

CMDLF, FILE, FILE2, CMDFILE, CMDMBR, CMDDBF, CMDDB.
129
LES FICHIERS LOGIQUES

Principes Prsentation Structure Utilisation Les diffrents types de fichiers logiques Les tapes de la cration d'un fichier logique Les fichiers logiques non-joints Principes La rfrence aux fichiers physiques Slection et omission Les chemins daccs Les redfinitions de zones Les fichiers logiques multiformats Conclusions sur les fichiers logiques non joints Les fichiers logiques joints Principes La codification Remarques Conclusions sur les fichiers logiques joints Les principaux mots-cls des DDS des fichiers logiques Les DDS de niveau Fichier Les DDS de niveau Format Les DDS de niveau Zone Les DDS de niveau Cl Les DDS de niveau Slection La commande de cration des fichiers logiques Les membres Le programme slecteur de format Estimation de la taille d'un fichier logique Les principaux paramtres de la commande CRTLF Les membres Les chemins daccs Performances Les limites La reconstruction
83
83 83 83 85 90 91 91 91 92 94 97 99 102 108 109 109 109 114 115 116 116 116 117 118 118 118 118 119 119 119 120 123 123 123 125
130
La sauvegarde La gestion des fichiers logiques La dfinition La destruction La visualisation Les membres La sauvegarde Les utilitaires Conclusions sur les fichiers logiques Les principales commandes Les principaux menus
126 126 126 126 126 127 127 127 128 128 128
A
ADDLFM ALL
117; 122
94
C
CA/400 112 CHAIN 101 chemin daccs 96; 119 CHGLF 120 CHGPF 120 CMP 94 CONCAT 98 CRTLF 91; 115; 120 CRTPF 120
D
DFU 111; 122 DLTF 121 DSPFD 96; 116 DTAMBRS 115 DYNSLT 97; 109; 111
E
EDTOBJAUT ET
88
95
84
F
fichier logique 83 fichier logique joint 106 fichier logique multiformat 100 fichier logique non-joint 91 FMTSLR 104
I
IBM/36 104 identificateur de format 86
J
109 108 JFILE 107 JFLD 107 JOIN 107
JDFTVAL JDUPSEQ
M
membre 117
O
omission 93 OPNQRYF 112; 119 OU 95 OVRDBF 121
P
PCS/400 112 PFILE 91
Q
QSYSTRNTBL
99
Query 112
R
94 101 RECOVER 120 REFACCPTH 96 RENAME 98 RMVM 121
RANGE READE
85
RPG 85
S
sauvegarde 121 Scurit 87 slecteur de format 104 Slection 93 SGBDR 83 SQL 119
U
Union 93 UNIQUE 89
V
VALUES
94
W
WRITE
104
Chapitre 5
Scurit et intgrit des donnes
Introduction
De nombreux vnements tels que dfaut dun composant, incendie, inondation, sabotage... peuvent provoquer la perte de tout ou partie des donnes dun systme. LOS/400 fournit de nombreuses mthodes de protection de linformation qui permettent dassurer lintgrit et la scurit des donnes. Intgrit des donnes signifie que les informations contenues dans la base de donnes sont dans un tat stable et cohrent. Les donnes sont valides et surtout elles sont cohrentes entre elles. La scurit correspond lensemble des fonctions qui assurent quun utilisateur ne fait que ce qui lui est permis de faire. Pour assurer lintgrit et la scurit des donnes, lAS/400 propose des dispositifs logiciels et matriels rsums dans le tableau suivant :
Nom Batterie Nature Matriel (sur certains modles seulement) Description Permet au systme de terminer normalement les oprations en cours lors dune coupure prolonge dalimentation.
126
Disques miroir Matriel
Contrle dintgrit (checksum)
Matriel
RAID5
Matriel (avec les disques adquats)
ASP utilisateur
Logiciel
Journalisation
Logiciel
Contrle de validation Sauvegarde
Logiciel
Logiciel
Contrle dintgrit Dclencheurs
Logiciel Logiciel
La structure de stockage est ddouble. Chaque disque est associ un deuxime disque de mme type qui contient exactement les mmes donnes. Le systme crit sur ces deux supports en mme temps. Si lun deux tombe en panne, les oprations continuent avec son image sans interruption des applications. Pour une srie de disques identiques, une information de contrle est place sur un des supports et permet de reconstituer un des disques en cas de problme. La reconstruction de ce disque seffectue alors que les applications sont arrtes, le systme ne pouvant redmarrer quaprs rcupration complte de lunit dfaillante. Ne pas confondre avec le contrle dintgrit rfrentielle qui est une fonction logicielle. Le principe est le mme quavec le contrle dintgrit (checksum) mais cest le contrleur des disques qui gre les oprations. Si un disque tombe en panne, le systme ne sarrte pas, cest le contrleur qui se charge de reconstituer les donnes la demande. Lintervention sur ces units se produit sans arrter le systme. Lensemble de la mmoire secondaire est dcoup en plusieurs espaces de stockages appels ASP. En cas de problme sur un disque, seules les donnes de lASP qui contient ce disque sont affectes. A chaque action modifiant un fichier (criture, suppression, modification), une information est place dans un journal indiquant la nature de cette opration. Si un arrt anormal du systme se produit avant que le fichier lui-mme ne soit mis jour, lopration sera automatiquement effectue par lOS/400 au prochain IPL, partir des informations du journal. Assure que toutes les oprations dune transaction sont effectues (ou annules). Cette fonction sappuie sur la journalisation. Copie les objets de la base de donnes sur un support externe (bande, cartouche...) pour pouvoir ventuellement les restaurer ultrieurement en cas de problmes. Permet dtablir une contrainte dexistence entre des zones de deux fichiers. Permet de lancer un programme lorsque survient un vnement li la base de donnes (avant insertion dun enregistrement, par exemple).
Ces diffrentes fonctionnalits sont traites ci-aprs.
5 - Scurit et intgrit des donnes
127
La journalisation
La journalisation est la fonction de base qui permet de prserver lintgrit des donnes. Elle doit tre considre avec attention lors de la dfinition de la stratgie de protection de linformation.
Les principes Introduction

La journalisation est lune des composantes essentielles de la stratgie de sauvegarde de la base de donnes. Mais elle est aussi utilise par le systme pour ses propres fonctions. Nous allons, dans cette premire section, dfinir les principes gnraux de la journalisation, puis nous traiterons de son apport pour la base de donnes. Quand un changement est effectu sur un fichier journalis, des informations sur cette opration sont places dans un objet appel rcepteur de journal (de type *JRNRCV) avant que la modification proprement dite ne soit applique au fichier. Cette information, appele poste, contient des donnes sur le travail (utilisateur, identification du travail, programme, date, heure...), limage de lenregistrement aprs modification et ventuellement limage de lenregistrement avant modification. Le systme place galement dans les rcepteurs des informations pour identifier les actions les plus importantes effectues sur les fichiers : sauvegarde, restauration, initialisation, rorganisation et mme IPL. Le premier intrt de la journalisation consiste diminuer les problmes lis un arrt anormal du systme. Nous avons dj signal au chapitre 3 que les oprations sur les enregistrements peuvent tre considres comme effectues, pour un utilisateur, alors que les mises jour ne sont pas rellement crites sur disque, mais sont simplement appliques en mmoire principale. En cas darrt brutal du systme, les donnes correspondantes peuvent tre perdues. Avec la journalisation, le systme vrifie lIPL si les rcepteurs sont bien synchroniss avec les fichiers. Autrement dit, il sassure que tout ce qui est dans les rcepteurs de journaux est rellement crit dans les fichiers. Si ce nest pas le cas, il effectue automatiquement les mises jour correspondantes. A partir du moment o linformation est place dans un rcepteur de journal, elle peut donc tre considre comme rellement crite sur disque.
128
Le deuxime intrt de la journalisation rside dans la possibilit dannuler, ou au contraire de refaire, chacune des oprations enregistres dans le rcepteur. Voici deux situations caractristiques: en cas derreur grave sur un fichier, comme une destruction accidentelle, par exemple, il est toujours possible de restaurer la dernire version de ce fichier et dappliquer toutes les modifications enregistres depuis sa sauvegarde par la journalisation (sauf peut tre la dernire si elle est lorigine de la destruction). Les postes du journal doivent seulement contenir limage des enregistrements aprs modification (appele image aprs) ; en cas derreur de saisie, on peut enlever les oprations qui correspondent tout ou partie dun travail, condition de matriser parfaitement les transactions concernes (plusieurs fichiers pouvant tre concerns). Limage de lenregistrement avant modification (image avant) doit alors figurer dans le journal pour pouvoir remonter les transactions. La journalisation dun fichier physique peut sappliquer soit sur limage aprs, soit sur les images avant et aprs. Cest au dmarrage de la journalisation dun fichier physique que lon choisit le type de poste gnrer. Il est clair que lutilisation des deux types dimages est plus riche fonctionnellement, mais elle consomme un peu plus de ressources (CPU et disque). Il appartient chacun de trouver le bon quilibre pour chacun des fichiers de son systme.
La structure
Pour la base de donnes, la journalisation sapplique aux fichiers physiques et aux fichiers logiques. Pour ces derniers, il sagit de protger uniquement les chemins daccs. Un fichier journalis est rattach un journal. Cet objet, de type *JRN, ne contient aucune donne proprement dite, mais permet seulement de dfinir les caractristiques de la journalisation. Un journal est rattach un rcepteur de journal qui va recevoir les donnes. Un poste est un enregistrement dun rcepteur, il correspond tout ou partie dune opration. La figure 5.1 prsente la structure de la journalisation. Compte-tenu des diffrents objets participant la journalisation, il faut respecter des tapes bien prcises avant de journaliser un fichier.
129
TRAVAIL
Fichier physique Fichier logique
Informations de journalisation
Journal *JRN
Un poste Rcepteur de journal *JRNRCV
Figure 5.1 : principe de la journalisation.
La mise en place
Le rcepteur de journal est le premier objet que lon doit crer, ceci grce la commande CRTJRNRCV. Il est alors possible de crer un journal rattach au rcepteur prcdemment dfini en utilisant la commande CRTJRN. Il reste alors dfinir les fichiers physiques et logiques qui seront associs ce journal par les commandes STRJRNPF et STRJRNAP. Voici un exemple simple :
/*Cration du rcepteur de journal RECEPT dans la bibliothque PROD*/ CRTJRNRCV JRNRCV(PROD/RECEPT) /*Cration du journal JRN dans la bibliothque PROD*/ /*rattach au rcepteur prcdemment dfini*/ CRTJRN JRN(PROD/JRN) JRNRCV(PROD/RECEPT) /*Dmarrage de la journalisation pour le fichier PF1 avec*/ /*images avant et aprs*/
130
STRJRNPF FILE(PROD/PF1) JRN(PROD/JRN) IMAGES(*BOTH)
131
Les rcepteurs de journaux

Dtachement Un rcepteur de journal est un objet sans taille qui sagrandit au fur et mesure des besoins (jusqu une limite suprieure 2 milliards de postes, si vos disques le permettent !). Il est important de dtacher un rcepteur devenu trop gros pour le remplacer par un nouveau. Il est ainsi libr du journal. Pour simplifier, et mme automatiser ce travail, nous pouvons indiquer une taille, en kilo-octets, en regard du paramtre THRESHOLD de la commande CRTJRNRCV. Lorsque la taille du rcepteur atteint ce seuil, le message CPF7099 est envoy la file dattente de messages cite dans le paramtre MSG de la commande de cration du journal (CRTJRN), par dfaut QSYSOPR. Nous pouvons simplement automatiser le dtachement du rcepteur en associant un programme la file dattente ainsi dfinie. Depuis la V3R1M0 de lOS/400, la gestion des rcepteurs peut tre entirement laisse au systme si MNGRCV(*SYSTEM) est codifi pour le journal (dans les commandes CRTJRN ou CHGJRN). Le dtachement dun rcepteur est effectu par la commande CHGJRN. Le paramtre JRNRCV dfinit le nom du nouveau rcepteur qui est automatiquement cr. La valeur JRNRCV(*GEN) laisse au systme le soin de donner un nom au nouveau rcepteur. Dnomination Voici les rgles utilises pour la gnration automatique du nouveau nom : le nom sera compos au maximum de 6 caractres gauche et se terminera par 4 positions numriques ; si lancien nom possde plus de 6 caractres gauche, il sera tronqu 6 ; si lancien nom possde moins de 6 caractres gauche, ils seront conservs et ne seront pas complts 6 ; si lancien nom ne se termine pas par des caractres numriques, 0001 sera rajout aux caractres de gauche dj dfinis ; si lancien nom se termine par des caractres numriques, cette partie sera incrmente de 1 ; une erreur sera renvoye si la partie numrique est gale 9999.
132
La figure 5.2 illustre cette gnration automatique de nom.

Ancien nom R RCV RECEPTEUR RCV1 RECEPT9999 Nouveau nom R0001 RCV0001 RECEPT0001 RCV2 ERREUR !
Figure 5.2 : rgles utilises pour la gnration automatique de noms pour les rcepteurs de journaux.
Il est donc important de bien connatre ces rgles afin de choisir, ds le dpart, un nom adapt, par exemple 6 caractres gauche suivis de 0001 tel que RECEPT0001. Gestion Une fois dtach, un rcepteur de journal est dit EN LIGNE. Ses donnes sont disponibles pour toutes les fonctions de journalisation. Il est prudent de le sauvegarder (il est alors en tat SAUVEGARDE), et si les probabilits de son utilisation sont faibles, on peut le dtruire. La figure 5.3 rsume les diffrents tats des rcepteurs de journaux.
R0006
R0007
JOURNAL
SAVxxx
Rcepteurs de journaux R0007 ETAT SAUVEGARDE R0008 EN LIGNE R0009 ATTACHE
Figure 5.3 : organisation des rcepteurs de journaux.
133
Le rcepteur R0009 est attach au journal, cest lui qui reoit les postes de la journalisation. R0008 est en ligne, R0007 a t sauvegard. Les donnes de ces trois rcepteurs sont disponibles pour des oprations lies la journalisation. R0006 peut tre restaur.
Pour des raisons videntes de cohrence, il est important de conserver la continuit des rcepteurs ; on ne peut pas, dans lexemple de la figure 5.3 supprimer le rcepteur R0008, car la chane des rcepteurs serait alors brise.
Les journaux
Gestion La commande WRKJRNA permet de grer les attributs dun journal. Un premier cran prsente les caractristiques du journal et le rcepteur attach (figure 5.4).
Journal . . . . . . : Gestion des attributs de journal QACGJRN Bibliothque . . . . : QSYS
Pool mmoire sec . . : 1 Options taille File attente messages: QSYSOPR rcepteur . . . . : Bibliothque . . . : *LIBL Gestion rcepteurs . : *USER Suppress rcepteurs : *NO Texte . . . . . . . : Journal de comptabilit des travaux Indiquez vos options, puis appuyez sur ENTREE. 8=Afficher les attributs Rcepteur Option attach Biblio COMTRA0004 COMTRA
*NONE
Fin F3=Exit F12=Annuler F13=Fichiers journaliss F14=Chemins d'accs journaliss F15=Grer le rpertoire des rcepteurs
Figure 5.4 : gestion des attributs du journal QACGJRN par la commande WRKJRNA. Ce journal est utilis par le systme pour la comptabilit des travaux.
Gestion du rpertoire des rcepteurs Journal . . . . . . : QACGJRN Bibliothque . . . . : Taille totale des rcepteurs . . . . . . . . . . . . . . . . : Indiquez vos options, puis appuyez sur ENTREE. 4=Supprimer 8=Afficher les attributs Opt Rcepteur Biblio Numro attach Etat COMTRA0001 QSYS 00001 15/02/95 SAUVEGARDE COMTRA0002 QSYS 00002 25/02/95 EN LIGNE COMTRA0003 QSYS 00003 30/03/95 EN LIGNE COMTRA0004 QSYS 00004 06/01/96 ATTACHE F3=Exit F5=Rafficher F11=Taille F12=Annuler QSYS 319488
sauveg 10/03/95 00/00/00 00/00/00 00/00/00 Fin
134
Figure 5.5 : gestion des rcepteurs du journal QACGJRN par la commande WRKJRNA puis appui sur F15. Le rcepteur COMTRA0004 est attach, COMTRA0002 et COMTRA0003 sont dtachs et ne sont pas encore sauvegards, COMTRA0001 est dtach et a t sauvegard le 10/03/95.
Sur cet cran, des touches de fonction permettent de grer les rcepteurs (F15), de visualiser les fichiers (F13) et les chemins daccs (F14) journaliss (figure 5.5).
WRKJRN est la commande de gestion des journaux. Elle permet notamment de voir tous les journaux du systme (figure 5.6).
Gestion de la journalisation Indiquez vos options, puis appuyez sur ENTREE. 2=Rtablissement avant 3=Rtablissement arrire 5=Etat du journal 6=Rtablir journal endommag 7=Rtablir rcepteurs de journal endommags 9=Rcepteurs associs au journal Opt Journal QACGJRN QAUDJRN QAOSDIAJRN QCQJMJRN QDSNX QLYJRN QLYPRJLOG QLZALOG QMAJRN QO1JRN QSNADS Biblio QSYS QSYS QUSRSYS QUSRSYS QUSRSYS QUSRSYS QUSRSYS QUSRSYS QUSRSYS QUSRSYS QUSRSYS Texte Journal de comptabilit des travaux Journal for DIA files JOURNAL FOR MANAGED SYSTEM LOG JOURNAL FOR DSNX LOG
Journal for license management JOURNAL FOR ORDER DATABASE Journal for SNADS files A suivre...
Commande ===> F3=Exit
F4=Invite
F9=Rappel
F12=Annuler
Figure 5.6 : gestion des journaux par la commande WRKJRN. Tous les journaux du systme ont t slectionns.
Extraction dinformations La journalisation peut tre utilise pour scuriser la base de donnes, nous en reparlerons dans les sections suivantes. Elle peut aussi servir des applications qui vont traiter les donnes contenues dans les postes, pour gnrer par exemple des rapports dactivits ou des traces lors de dbogage. Cela apparat dautant plus intressant quand on sait que des fonctions systme comme la comptabilit des travaux et laudit sappuient sur la journalisation.
135
La commande DSPJRN permet dextraire les postes dun journal pour les placer dans un fichier, pour les afficher lcran ou pour les imprimer. Chaque poste est caractris par un code et par un type qui indiquent quoi correspondent les donnes quil contient. La liste des principaux types et codes est fournie dans lannexe B. La figure 5.7 prsente une copie dun cran affich par la commande DSPJRN.
Postes du journal Journal . . . . . . : QACGJRN Bibliothque . . . . : Indiquez vos options, puis appuyez sur ENTREE. 5=Afficher le poste complet Squence Code 13459 J 13461 A 13462 A 13463 A 13464 A 13465 A 13466 A 13467 A 13468 A 13469 A 13470 A 13471 A F3=Exit F12=Annuler Opt 5 Type PR JB JB JB JB JB JB JB JB JB JB JB Objet Biblio Travail PCCGS1 PREPARDATE CLIENT1 PCCGS1 PCCGS1 CLIENT1 PCCPS2 PCCP PCCP QXFSERV PCCP PCCP QSYS
Heure 10:08:19 10:09:51 11:50:35 11:53:27 11:53:29 11:56:54 13:48:22 13:48:30 13:48:33 13:49:06 14:36:28 14:36:28 +
Figure 5.7-a : cran de la commande DSPJRN applique au journal QACGJRN de QSYS correspondant la Comptabilit des travaux de lOS/400. Le premier poste (code J, type PR) correspond au prcdent rcepteur. Les postes A-JB dcrivent un travail.
Poste de journal Objet . . . . . . . : Bibliothque . . . . : Membre . . . . . . . : Squence . . . . . . : 13459 Code . . . . . . . . : J - Opration journal ou rcepteur de journal Type . . . . . . . . : PR - Prcdents rcepteurs de journal Donnes spcifiques du poste Colonne *...+....1....+....2....+....3....+....4....+....5 00001 'COMTRA0001COMTRA ' Fin Appuyez sur ENTREE pour continuer. F3=Exit F6=Donnes du poste seulement F10=Dtails du poste seulement F11=Format hexadcimal F12=Annuler F24=Autres touches
Figure 5.7-b : visualisation dun poste du journal de type J-PR. Cet cran est affich aprs la saisie de loption 5 en regard du premier poste de la figure 5.7-a. Le prcdent rcepteur tait COMTRA0001 de la bibliothque COMTRA.
136
La commande DSPJRN permet de slectionner les postes traiter en fonction de nombreux critres tels que certains rcepteurs de journaux, les dates et heures de dbut et de fin, lidentification dun travail, le type de poste... Lenvoi des postes vers un fichier physique permet de mettre en forme les donnes de la journalisation. Pour la comptabilit des travaux, par exemple, le format des enregistrements est celui du fichier QADSPJRN (ou QADSPJR2) de QSYS.
Optimisation
Une bonne utilisation des paramtres et une gestion rigoureuse assurent une journalisation scurise et efficace. Nous allons maintenant voir comment optimiser les principaux aspects de la journalisation. La scurit Les donnes contenues dans les rcepteurs sont utilises pour redmarrer rapidement les applications aprs un incident. Elles permettent notamment de replacer la base de donnes dans un tat stable et cohrent par application des postes sur les fichiers restaurs. A ce titre, les rcepteurs peuvent tre considrs comme critiques au niveau de la scurit. Pour augmenter la fiabilit de la journalisation, il est possible de placer les rcepteurs dans un ASP diffrent de celui qui contient les fichiers. Il suffit pour cela de les rattacher une bibliothque situe dans lASP adquat (commande CRTJRNRCV). En cas de problme sur lASP qui contient les fichiers, il est simple de reconstruire la base de donnes partir des sauvegardes et des rcepteurs qui ont t pargns car isols dans un autre ASP. Si cest lASP contenant les rcepteurs qui subit lincident, cela na aucun effet sur les fichiers qui sont prservs par leur situation sur un autre disque. Cette scurit peut encore tre accrue car un journal peut tre attach 2 rcepteurs (situs si possible dans des ASP diffrents). Les informations sont alors crites simultanment sur ces 2 objets. En cas dincident, on peut esprer quil y en aura toujours un en parfait tat. Cest dans la commande CRTJRN que lon doit saisir le nom de ces deux rcepteurs. Place occupe Pour la journalisation des fichiers physiques, la taille dun poste, en octet, peut tre estime par la formule :
137
78 + taille dun enregistrement o 78 reprsente les entres systme. Ainsi, pour un enregistrement de 122 octets de long, le poste cr occupera environ 200 octets. Si le fichier est journalis avec image avant et aprs (STRJRNPF IMAGES(*BOTH)), chaque enregistrement modifi gnre deux postes. Dans ce cas, la taille du rcepteur est plus importante que si le fichier tait journalis en image aprs seulement. La diffrence parat toutefois minime, moins que les enregistrements ne soient constamment modifis. Il est donc conseill de choisir la journalisation complte (image avant et aprs) qui procure un maximum de fonctionnalits, dautant que le supplment de CPU consomm peut paratre ngligeable. Toujours pour la journalisation des fichiers physiques, il faut ajouter aux postes directement lis aux enregistrements des postes gnrs par la gestion des fichiers. Chaque opration effectue sur un fichier journalis cre au moins un poste. Cest le cas pour certaines commandes (CLRPFM, INZPFM, RMVM, DLTF, MOVOBJ, RNMOBJ, SAVOBJ, SAVLIB...) et pour chaque ouverture et fermeture. Ces dernires entres peuvent tre omises du journal si OMTJRNE(*OPNCLO) est spcifi pour la commande STRJRNPF. Les performances lors de louverture et de la fermeture des fichiers sont ainsi amliores et la taille des rcepteurs est diminue. Par contre, les paramtres TOJOBO et TOJOBC des commandes APYJRNCHG et RMVJRNCHG ne seront plus utilisables car ils font rfrence louverture et la fermeture des fichiers. Ces commandes sont traites au sous-chapitre consacr la journalisation des fichiers physiques. Performances La journalisation des fichiers physiques est rpute pnalisante sur le plan des performances. Il est donc important de grer au mieux cette fonction afin dobtenir des temps de rponse minima. Certains paramtres permettent une relative optimisation. Nous avons dj signal au chapitre prcdent lintrt du paramtre OMTJRNE pour ne pas ralentir les ouvertures et fermetures de fichiers, et de la mise en uvre ventuelle de limage avant seulement. Il est important de bien comprendre le fonctionnement de la journalisation pour rpartir efficacement les charges de travail des bras daccs disques afin dviter les goulots dtranglement. Lcriture dun poste dans un rcepteur peut tre considre comme synchrone dans la mesure o elle seffectue immdiatement au
138
dbut de la phase dcriture. La mise jour du fichier lui-mme seffectuera ensuite une fois que le poste aura physiquement t crit sur le disque. De plus, comme nous lavons dj signal, la modification du fichier seffectue dabord en mmoire principale puis est rpercute sur les disques ultrieurement, en gnral lorsque le systme le dcide. La phase dcriture du rcepteur de journal est critique car plus elle est lente et plus lensemble des transactions avec les fichiers journaliss est pnalis. Il faut donc librer au maximum toutes les ressources qui interviennent ce niveau, notamment les bras daccs disque. Lcriture tant synchrone, il faut attendre que la tte soit libre pour aller crire linformation. Si celle-ci est trs occupe, les performances sont alors notablement dgrades. Il peut tre intressant de placer le rcepteur dans un ASP utilisateur peu sollicit (si possible diffrent de celui qui contient les fichiers). Outre les avantages en terme de scurit dj dcrits, cette organisation peut amener un gain substantiel au niveau des performances. Il faut quand mme rajouter que ces points dtranglement nexistent pratiquement pas sur les nouveaux disques IBM tels que les 9337. En effet, ils disposent dune importante mmoire cache en criture ce qui fait que les applications nattendent pratiquement plus la libration des bras daccs. Linformation est considre comme crite ds quelle est place dans la mmoire cache. Cette dernire est extrmement rapide (elle est de type RAM) et non volatile en cas de panne (elle est auto-alimente), ce qui lui procure des temps de rponses exceptionnels tout en assurant une scurit optimale. Enfin, il faut noter que plus le nombre de fichiers journaliss est important, plus les performances sont dgrades. Sauvegarde et restauration Un rcepteur de journal peut tre sauvegard laide des commandes classiques et SAVCHGOBJ. Un rcepteur attach peut tre sauvegard mais il sera incomplet. Sa restauration donnera un rcepteur dans un tat PARTIEL, cest-dire ne contenant pas tous les postes. Lors dune restauration complte, il est important de restaurer les objets lis la journalisation dans lordre suivant : les journaux en premier ; puis les fichiers physiques journaliss ; puis les fichiers logiques dpendants de ces fichiers physiques ;
SAVOBJ, SAVLIB
139
et enfin les rcepteurs de journaux du plus rcent au plus ancien. Aprs une sauvegarde effectue par SAVLIB LIB(*NONSYS) ou SAVLIB LIB(*ALLUSR), la restauration ne pose aucun problme si tous les objets lis la journalisation sont placs dans la mme bibliothque car lordre est automatiquement respect par le systme. Si ces objets sont dans des bibliothques diffrentes, il faut sassurer que la restauration seffectue dans le bon ordre.
140
Postes utilisateurs La commande SNDJRNE permet de crer des postes utilisateurs dans un journal. Le code du poste est U et le type est dfini par le paramtre TYPE de cette commande. Les donnes du poste sont prcises au niveau du paramtre ENTDTA. Ces postes sont trs pratiques lors de lanalyse des journaux car ils permettent de bien identifier le dbut et la fin dune opration. Pour tre encore plus prcis, il est mme possible dassocier chacune de ces entres un fichier physique grce au paramtre FILE.
La journalisation des fichiers physiques Le but

La journalisation des fichiers physiques a pour objet dassurer lintgrit des donnes lors dincidents tels que : larrt anormal du systme ; la destruction accidentelle dun fichier ; les erreurs de saisies majeures. Chaque opration sur un enregistrement journalis tant mmorise dans un rcepteur, il est simple deffectuer nouveau cette opration partir dune sauvegarde (cest le recouvrement avant) ou de lenlever si elle a t commise par erreur (recouvrement arrire).
Le dmarrage
Nous avons dj dcrit prcdemment comment crer un environnement de journalisation (rcepteurs et journaux). La commande STRJRNPF permet de dmarrer la journalisation dun fichier physique. On doit y indiquer le nom du journal et du fichier physique. Le paramtre IMAGES(*AFTER) prcise que seule limage aprs est conserve alors que IMAGES(*BOTH) indique que les images avant et aprs sont retenues. Enfin, OMTJRNE(*OPNCLO) empche la cration de postes lis louverture et la fermeture du fichier. Jusqu 50 fichiers peuvent tre ainsi journaliss en une seule opration.
141
Ds que la journalisation est effective pour un fichier, et avant de modifier ses donnes, il faut obligatoirement le sauvegarder. La sauvegarde servira de point de synchronisation en cas de recouvrement avant et il est donc essentiel quelle figure au tout dbut du rcepteur. Un poste de type FMS est ajout lors de la sauvegarde dun membre.
Le recouvrement avant
En cas de perte dun fichier (par destruction accidentelle, par exemple), il est possible de restaurer le fichier et dappliquer tous les postes contenus dans les rcepteurs de journaux (sauf peut-tre le dernier sil est responsable de la perte des donnes) par la commande APYJRNCHG. Les paramtres par dfaut de cette commande font rfrence la dernire sauvegarde (*LASTSAVE). Cette opration de reconstruction standard dun fichier est donc extrmement simple : restauration de la dernire sauvegarde ; application des modifications par APYJRNCHG. Dans le cas o cette reconstruction demande lomission de certains postes, il faut analyser les rcepteurs concerns grce la commande DSPJRN. Dans la commande APYJRNCHG la slection de postes peut se faire partir de leur numro dordre, en fonction dune date et dune heure, jusqu une frontire de rcepteurs ou en fonction de lidentification dun travail ( condition de ne pas avoir codifi STRJRNPF OMTJRNE(*OPNCLO)). Loption 2 de la commande WRKJRN propose une interface au-dessus de cette commande de recouvrement avant. Certains traitements effectus sur un fichier ne permettent pas dexcuter un recouvrement avant car cette opration applique les modifications contenues dans les postes des rcepteurs. Pour certaines oprations, aucune information lie aux enregistrements nest contenue dans les postes. La commande DLTM, par exemple, dtruit un membre et ne cre quun seul poste de type F-CR o ne figure aucune indication sur les donnes supprimes. Il en est de mme pour la commande RGZPFM, pour les restaurations de membres et pour les modifications de la journalisation (arrt, APYJRNCHG, RMVJRNCHG).
142
Lors du recouvrement avant, le systme sarrte ds quil trouve un poste correspondant ces commandes et envoie un message dans lhistorique du travail, ou mme provoque une erreur (pour APYJRNCHG et RMVJRNCHG). Il est alors important de vrifier, par la commande DSPJRN, jusquo a t effectu le recouvrement. Lannexe B prsente les principaux types de postes de journaux. Rappelons que seule limage aprs est ncessaire pour le recouvrement avant.
Le recouvrement arrire
Le recouvrement arrire consiste enlever les oprations ralises sur un fichier. Il faut pour cela disposer des images avant afin de remettre lenregistrement dans ltat o il tait avant modification. Le recouvrement arrire est utile pour corriger une erreur de saisie ou pour enlever une partie des oprations dune transaction qui sest mal termine, alors que le contrle de validation na pas t mis en place. Il ne sert pas rcuprer un fichier dtruit ou endommag, ce qui est du domaine du recouvrement avant. Aucune restauration ntant effectuer, le recouvrement arrire est simplement ralis par la commande RMVJRNCHG. Il est essentiel davoir analys les rcepteurs de journaux (DSPJRN) pour savoir quels sont les postes enlever. Attention aux transactions qui affectent plusieurs fichiers ! Il faudra penser appliquer le recouvrement arrire sur tous. Les postes enlever peuvent tre slectionns en fonction des rcepteurs, des numros de squence et de lidentification dun travail. De la mme manire que pour le recouvrement avant, le recouvrement arrire sarrte lorsquil arrive sur un poste correspondant aux commandes ayant restructur le membre telles que DLTM, SAV.. STG(*FREE), RGZPFM, RST... et mme CLRPFM.
Conclusions
La journalisation des fichiers physiques est en train de devenir incontournable. Elle est plus ou moins obligatoire dans le cas o une application accde des bases de donnes situes sur plusieurs systmes (DRDA), pour le contrle dintgrit rfrentielle, pour SQL... Dans dautres environnements, la journalisation fait partie intgrante du systme de gestion de base de donnes et ne
143
peut tre dsactive. Il parat donc indispensable de journaliser les fichiers importants. Mais cela nest pas (encore) dans la culture des concepteurs dapplications AS/400 car la journalisation a, ds le dbut, t considre comme une fonction facultative ralentissant les applications. Avec les gains notables de puissance des machines actuelles (pour un moindre cot), la journalisation devrait tre vue comme une fonction naturelle, couramment utilise. Avec la journalisation seule, le travail de reprise est parfois complexe dans la mesure o il faut se plonger dans lanalyse des rcepteurs tout en matrisant parfaitement les applications, surtout si plusieurs fichiers sont concerns. Le but tant de conserver la base de donnes dans un tat stable et cohrent, le contrle de validation peut tre rajout la journalisation pour laisser au systme et aux applications le soin de grer automatiquement les reprises, tout en assurant une parfaite cohrence dans les transactions.
La journalisation des chemins daccs Le but

Nous avons dj signal que larrt anormal du systme peut provoquer une incohrence entre un fichier physique et ses diffrents chemins daccs. Lorsque le systme dtecte une telle anomalie, il reconstruit les chemins daccs concerns au moment qui est dfini par le paramtre RECOVER du fichier (physique ou logique) correspondant ce chemin daccs. Il peut avoir pour valeur : *IPL : la reconstruction a lieu lors de lIPL ; *AFTIPL : la reconstruction a lieu aprs lIPL ; *NO : la reconstruction se fera la premire ouverture du fichier. La commande EDTRBDAP permet de contrler la reconstruction de tous les chemins daccs concerns ds la fin de lIPL. Aprs un arrt anormal, il est clair que la dure de lIPL dpend directement de la taille des chemins daccs reconstruire. On estime gnralement quil faut une minute au systme pour reconstruire un chemin daccs de 10 000 enregistrements. Cette estimation peut varier sensiblement en fonction du modle dAS/400, des types de disques et mme de la version de lOS/400. Cette valeur nous permet dimaginer quil faut environ une centaine de minutes pour recrer un chemin daccs dun million denregistrements, soit un peu plus dune heure et demie !
144
Il nest pas rare davoir de tels fichiers. Il semble donc essentiel de protger les chemins daccs afin de minimiser le temps des IPL qui suivent un arrt anormal. La scurit de base consiste sauvegarder les chemins daccs avec les fichiers physiques. La restauration de ces fichiers et des chemins daccs est prfrable (quelques minutes) la reconstruction (jusqu plusieurs heures !). La journalisation des chemins daccs assure une parfaite synchronisation entre le fichier physique et ses chemins daccs. Elle permet ainsi de fortement diminuer le temps de lIPL qui suit un arrt anormal. Il faut remarquer que ces deux fonctions (sauvegarde et journalisation) ne protgent aucune donne, mais quelles permettent seulement de conserver une cohrence entre un fichier physique et ses chemins daccs.
Le dmarrage
La commande STRJRNAP permet de lancer la journalisation dun chemin daccs. Sa syntaxe est extrmement simple :
STRJRNAP FILE(NOMFICH) JRN(NOMJRN)
o NOMFICH est le nom de un cinquante fichiers (physiques ou logiques) et NOMJRN est le nom du journal. Si le nom dun fichier physique est cit, seul le chemin daccs de ce fichier (celui dfini au niveau Cl des DDS) est journalis. Il faut penser lancer cette commande pour tous les fichiers logiques qui pointent sur ce fichier. Les chemins daccs de tous les membres dun fichier sont ainsi journaliss, on ne peut choisir tel ou tel membre.
Quelques restrictions
Tous les fichiers physiques sous-jacents un fichier logique et ce fichier logique doivent tre journaliss dans le mme journal. Les chemins daccs journaliss doivent avoir t crs avec les paramtres suivants : MAINT(*IMMED) ou MAINT(*DLY) ;
145
FRCACCPTH(*NO). Les fichiers physiques sous-jacents doivent tre journaliss en image avant et aprs (IMAGE(*BOTH)). Ci cela nest pas le cas, cest--dire si seule limage aprs a t retenue (IMAGE(*AFTER)), le systme ajoutera automatiquement loption image avant pour ces fichiers. La commande ENDJRNAP permet darrter la journalisation dun chemin daccs. La consommation de ressources de cette fonction est considre comme relativement faible car lcriture des postes concernant les chemins daccs et des postes relatifs aux enregistrements est effectue dans la mme opration dentre/sortie. Autrement dit, le systme ne mobilise la tte daccs disque quune seule fois. La journalisation des chemins daccs est une fonction essentielle pour une bonne gestion de son AS/400, si bien quelle est maintenant totalement prise en charge par le systme avec SMAPP
SMAPP
SMAPP (System Managed Access Path Protection) est une fonction totalement intgre au systme depuis la version V3R1M0 de lOS/400. Le principe est simple : on indique au systme le temps maximum quil doit passer reconstruire les chemins daccs lors dun IPL aprs arrt anormal du systme, et cest tout ! SMAPP fait le reste, cest--dire quil journalise automatiquement les chemins daccs quil juge sensibles (les plus gros, en gnral). Cette fonction est totalement transparente si bien que bon nombre de possesseurs dAS/400 ignorent son existence. Configuration A partir de la V3R1M0 de lOS/400, SMAPP est automatiquement dmarre avec un temps standard de reconstruction de cent cinquante minutes (2H30). La commande EDTRCYAP permet de modifier en interactif cette dure (figure 5.8). Chaque ASP peut tre gr indpendamment et des indications sont donnes sur lespace disque occup par les donnes de journalisation.
Rvision du rtablissement des chemins d'accs Estimation temps de rtablissement par le systme : Total de la mmoire disque utilise . . . . . . . : ALIZES 06 06 95 17:07:09 35 Minutes 0,024 Mo
146
% de mmoire disque utilise
. . . . . . . . . . :
0,002
Indiquez vos modifications, puis appuyez sur ENTREE. Temps de rtablissement par systme . . 60 *SYSDFT, *NONE, *MIN, *OFF, Temps -Temps de rtablissement des chemins d'accs- Mmoire disque utilise ASP Vis (minutes) Estim (minutes) Mgaoctets % ASP (Aucun ASP utilisateur configur ou aucune information disponible) F3=Exit F4=Invite F5=Rafficher F12=Annuler
Figure 5. 8 : cran de la commande EDTRCYAP.
Le temps minimal de recouvrement est fix 10 minutes et peut atteindre 24 heures. Il est clair que plus ce dlai est court et plus le nombre de chemins daccs journaliser est grand et, donc, plus limpact sur les performances est sensible. La commande CHGRCYAP permet de modifier les caractristiques de SMAPP dans un programme en langage de contrle, sans interaction avec un utilisateur. DSPRCYAP est utiliser pour afficher des informations sur cette fonction. La valeur *NONE au niveau de la dure arrte cette fonction. Elle ne pourra tre relance quen passant en mode restreint. Fonctionnement A lIPL, le systme examine tous les chemins daccs et, en fonction du temps de reconstruction estim et de la limite qui lui a t fixe, il dtermine ceux quil doit protger. Si les fichiers physiques sous-jacents aux chemins daccs slectionns sont journaliss, le systme utilisera leurs journaux. Sinon, il se servira de ses propres structures. Il ny a donc aucun objet crer ou maintenir. Le systme soccupe de tout, mme de faire le mnage auprs des rcepteurs devenus inutiles. Ne sont pas protgs les chemins daccs suivants : les temporaires (provenant de SQL, OPNQRYF, Query) ; ceux placs dans QTEMP ; ceux crs avec MAINT(*REBLD) ; ceux qui sont trop petits ; et ceux dont les fichiers physiques sous-jacents ne sont pas tous journaliss, ou le sont dans diffrents journaux.
147
Conclusion sur SMAPP Cette fonction est vraiment prendre en compte car elle assure des IPL aprs arrt anormal du systme relativement courts. Il est important de bien choisir une dure adapte ses besoins afin dobtenir une bonne adquation entre les ressources consommes et le temps dIPL. Elle remplace, ou plus exactement elle encapsule, la journalisation des chemins daccs quil devient inutile de grer soi-mme.
Conclusions sur la journalisation

La journalisation est lun des lments fondamentaux dune stratgie cohrente de protection des donnes. Elle devrait tre obligatoire pour les fichiers sensibles de lentreprise mais souffre, sur lAS/400, dun relatif ddain. Dans dautres environnements, le journalisation est incontournable et fait partie intgrante du systme de gestion de base de donnes. A lorigine de lAS/400, les machines de faible puissance obligrent considrer cette fonction comme facultative. Cest mon sens ce qui fait quaujourdhui elle nest pas passe dans les murs comme une fonction vitale, mais comme une sorte de gadget consommateur de ressources. La journalisation est obligatoire ds que lon travaille dans un environnement de base de donnes rparties. SQL, dailleurs, lutilise systmatiquement dans ses collections. Enfin, les nouvelles fonctionnalits de la V3R1M0 de lOS/400 obligent pratiquement journaliser certains fichiers physiques. Il est donc temps de sy investir...
Le contrle de validation
Principes
Lors dune criture comptable classique, au moins deux oprations sont effectues, la premire au crdit dun compte, la seconde au dbit dun autre. Ces deux oprations forment un tout et lon imagine aisment que la base de donnes se retrouverait dans un tat incohrent si une seule de ces critures tait prise en compte.
148
Une transaction est un ensemble doprations indissociables. Le contrle de validation a pour objet dassurer lintgrit des transactions. La loi du tout ou rien est applique. Toutes les oprations dune transaction sous contrle de validation doivent tre ralises ou, au contraire, toutes doivent tre annules. Le contrle de validation sappuie sur la journalisation. Il est relativement simple mettre en place si les transactions protger ont t mises en vidence lors de lanalyse.
149
Mise en uvre
Le contrle de validation dbute toujours par un programme en langage de contrle qui prpare lenvironnement grce la commande STRCMTCTL. Le programme qui effectue la gestion des enregistrements est ensuite appel. Enfin, la commande ENDCMTCTL arrte cette fonction. La structure de base du programme principal est donc:
STRCMTCTL CALL RPGXXX ENDCMTCTL
Les verrouillages
Quand les enregistrements dun fichier sous contrle de validation sont lus, ils peuvent tre verrouills par le systme. Le paramtre LCKLVL de la commande STRCMTCTL permet de dfinir prcisment le mode de verrouillage. Ses diffrentes valeurs peuvent tre : LCKLVL(*CHG) : un enregistrement lu en vue dune mise jour est verrouill. Si cet enregistrement est modifi, ou supprim, il reste verrouill jusqu la fin de la transaction, sinon il est libr la lecture de lenregistrement suivant ; LCKLVL(*CS) : tout enregistrement trait est verrouill. Dans le cas dune lecture, un enregistrement qui nest pas modifi est libr lors de laccs lenregistrement suivant. Les autres seront librs la fin de la transaction ; LCKLVL(*ALL) : tous les enregistrements traits sont bloqus jusqu la fin de la transaction. Il est clair que LCKLVL(*ALL) assure une plus grande cohrence mais peut verrouiller les enregistrements plus longtemps, mme dans le cas de lecture simple. Il est donc important de bien concevoir les applications pour ne pas provoquer des blocages inutiles par des lectures inopportunes.
Validation, invalidation
Une transaction dbute avec la premire opration sur un enregistrement dun fichier sous contrle de validation et se termine soit par un ordre explicite du langage (COMIT, ROLBK en RPG/400), soit par une commande de lOS/400
150
(COMMIT, ROLLBACK) soit, enfin, par une action implicite du systme (lors de la fin anormale du travail). La validation (ou commit) consiste terminer la transaction en acceptant toutes les modifications qui ont t effectues. Elle est provoque par lordre COMIT du RPG/400 ou par la commande COMMIT. Linvalidation (ou rollback) correspond lannulation de toute la partie de la transaction qui a dj t ralise. Elle est mise par un ROLBK en RPG/400 ou par la commande ROLLBACK. Le systme provoque une invalidation si une transaction est en cours la fin dun travail sous contrle de validation. Si cest un arrt anormal du systme qui a provoqu cette interruption, linvalidation sera effectue lIPL suivant, sinon elle aura lieu ds la fin du travail. Cest cette fonction qui assure la loi du tout ou rien pour une transaction. La validation ne modifie pas la position des pointeurs denregistrements (qui indiquent les enregistrements en cours de traitement). Par contre une rollback replace les fichiers dans ltat o ils taient avant le dbut de la transaction invalide. Les pointeurs denregistrements sont alors dplacs.
Structure du programme en langage de contrle

Un programme en langage de contrle doit prparer lenvironnement de validation par la commande STRCMTCTL. Il peut aussi servir clore des transactions complexes faisant intervenir plusieurs programmes laide des commandes COMMIT et ROLLBACK. La commande ROLLBACK peut tre systmatiquement utilise aprs lappel dun programme qui modifie les donnes. Si ce programme se termine en erreur, un message est renvoy au programme qui la appel par lintermdiaire de sa PGMQ. Il suffit de lintercepter et dmettre une invalidation pour tre sr que la transaction soit close et que les enregistrements soient librs. Sinon ils pourraient rester bloqus jusqu la fin du travail et les oprations de la transaction incomplte pourraient participer la transaction suivante et tre valides au prochain commit. Lexemple 5.1 reprsente cette interception.
PGM STRCMTCTL LCKLVL(*ALL) CALL PGMxx MONMSG MSGID(RPG0000) EXEC(ROLLBACK)
151
ENDCMTCTL ENDPGM
Exemple 5.1 : invalidation dune transaction la suite de la fin anormale du programme RPGXX.
Il faut remarquer que dans le cas o la transaction sest bien termine malgr la fin anormale du programme, la commande ROLLBACK na eu aucun effet car aucune transaction nest en cours.
Structure dun programme RPG

La structure dun programme RPG utilisant le contrle de validation est relativement simple. Dans les spcifications F, il faut dfinir les fichiers concerns avec le caractre de continuation K suivi de COMIT. La transaction dbute avec laccs au premier enregistrement dun fichier sous contrle de validation. La fin de cette transaction est caractrise par les codes opration COMIT ou ROLBK dans les spcifications C. La transaction suivante commencera avec le prochain accs aux donnes. Lexemple 5.2 prsente la structure dun programme RPG mettant en uvre le contrle de validation.
FFICH1 O E DISK FFICH2 UF E DISK C* C... C*Dbut de la transaction C WRITEFMT1 C... C READ FMT2 C UPDATFMT2 C DELETFMT1 c... C*Demande de confirmation par exemple C EXFMTCONFIR C* C*SI F12 ANNULATION DEMANDE = ROLLBACK C *IN12 IFEQ '1' C ROLBK C ENDIF C* C*SI F03 FIN NORMALE = COMMIT C *IN03 IFEQ '1' C COMIT C ENDIF C*TRAITEMENT DE FIN DE FICHIER C... C MOVE *ON *INLR KCOMIT KCOMIT A
152
Exemple 5.2 : structure dun programme RPG/400 avec contrle de validation. Les spcifications C suivies de trois points correspondent des traitements spcifiques de lapplication non reprsents.
Liens avec les sous-fichiers

Un sous-fichier sert dintermdiaire entre les donnes contenues dans les fichiers et un utilisateur. Son chargement est effectu partir denregistrements qui sont lus dans la base de donnes mais ne sont pas verrouills. On peut donc travailler avec des donnes qui sont dans un sous-fichier et qui ne refltent plus la ralit, un utilisateur ayant pu modifier les donnes initiales. Le contrle de validation permet de placer un verrou sur les enregistrements ds la premire lecture et de ne les librer qu la fin de la transaction. On est ainsi assur que les donnes contenues dans le sous-fichier sont jour. Il suffit pour cela de dmarrer un contrle de validation avec la commande suivante :
STRCMTCTL LCKLVL(*ALL)
Cette mthode a quand mme le gros inconvnient de verrouiller de nombreux enregistrements. On peut de ce fait facilement arriver des situations o les utilisateurs passent leur temps attendre la libration des donnes.
Lobjet de notification Principe

En cas darrt anormal dun travail ou du systme, lutilisateur ne sait pas toujours si les oprations quil tait en train de saisir lors de lincident ont vraiment t enregistres. Avec les objets de notification, le systme permet de connatre la dernire transaction valide. Le principe est relativement simple : le nom dun fichier (*FILE), dune zone de donnes (*DTAARA) ou dune file dattente de messages (*MSGQ) est cit dans la commande STRCMTCTL au niveau du paramtre NFYOBJ. En cas dincident, le systme crit dans cet objet des informations sur la dernire transaction valide. Ces informations proviennent de donnes associes au commit. En RPG, il sagit dune variable cite en facteur 1 de la ligne contenant le code opration COMIT. En langage de contrle, cest la valeur associe au paramtre CMTID de la commande COMMIT.
153
Fonctionnement
Lorsque le systme dtecte la fin anormale dun travail sous contrle de validation laissant une transaction incomplte, il met une invalidation. Il sappuie sur les postes contenus dans les journaux. Il recherche ensuite la dernire transaction valide de ce travail matrialise par un poste de code C et de type CM. Les donnes de ce poste correspondent en fait au contenu de la variable associe au commit. Il place ensuite ces informations dans lobjet de notification. Cet objet ne contient des donnes que lorsque le systme a mis une invalidation automatique. Au lancement dun programme mettant en uvre le contrle de validation, il suffit de vrifier si des donnes ont t places dans lobjet de notification. Si cest le cas, il faut extraire cette information et informer lutilisateur afin quil ressaisisse la transaction invalide. La structure de lobjet de notification est libre, cest chacun de la dterminer en fonction des informations quil dsire y trouver. La variable associe au commit devra avoir un format compatible. En RPG, par exemple, on prendra soin de dfinir une data-structure qui contiendra toutes les informations ncessaires : nom du travail, utilisateur, date et heure, identifiant de la transaction... Cest cette structure qui sera associe au code opration COMIT.
Les types
Les objets de notification peuvent tre soit des fichiers, soit des zones de donnes ou soit des files dattente de messages. Les zones de donnes ont pour inconvnient de ne contenir quune srie dinformations provenant dune seule invalidation. Elles ne sont donc utiliser que si un seul travail effectue de la saisie sous contrle de validation. Le cas o plusieurs utilisateurs seraient en train de mettre jour les donnes lors dun arrt anormal du systme ne pourrait tre trait avec ce type dobjet. Les fichiers et files dattente de messages peuvent contenir autant denregistrements quil peut y avoir dinvalidations de transactions la suite dun arrt anormal du systme. Il faut alors prendre soin de placer dans les donnes des informations qui permettront didentifier le travail ou (et) lutilisateur afin de rechercher pour chacun quelle a t la dernire transaction valide.
154
Si le programme de traitement est crit en RPG, il est prfrable de choisir un fichier comme objet de notification. Le traitement de ces objets est simple dans ce langage alors que la gestion des files dattente de messages ncessite lemploi dAPI. Une fois que le contenu de lobjet de notification a t trait, il faut le remettre blanc pour se replacer dans les conditions initiales.
155
Exemple
Lexemple 5.3 traite une application complte de saisie de factures sous contrle de validation. Lobjet de notification est une zone de donnes, il a t choisi pour que le source conserve une relative concision. DDS du fichier daffichage NOTIF Cet cran sert informer lutilisateur quune invalidation automatique a t ralise par le systme et indique quelle est la dernire facture valide.
DSPSIZ(24 80 *DS3) CA03(03) R FMTNOTIF 1 30'CONTROLE DE VALIDATION' COLOR(WHT) 4 3'Un incident a provoqu un arrt brutal du travail.' COLOR(BLU) 5 3'Le dernier enregistrement sauvegard est le suivant:' COLOR(BLU) 8 3'Nom du travail:' O 8 20 8 32'Utilisateur:' O 8 46 8 58'Facture:' O 8 68 23 3'F3=Arrt'
NOM JOB NOFAC
10 10 6
DDS du fichier physique ENTETE Il contient la description de len-tte de la facture.

R FMT1 NUMFAC NUMCLI DATE 6 5 6
DDS du fichier physique DETAIL Il contient les lignes de dtail de toutes les factures.
R FMT2 NUMFAC NUMART QTE PRIXU 6 5 6 5
1 2
156
157
Source du programme principal en langage de contrle (NOTIF) Ce programme vrifie si des donnes sont prsentes dans lobjet de notification et ventuellement les traite. Il place ensuite le travail dans un environnement de validation et lance le programme RPG1 de traitement des donnes.
PGM DCLF GAYTE/NOTIF DCL &INFO *CHAR 26 /*TEST DU RTVDTAARA IF (&INFO CHGVAR CHGVAR CHGVAR CONTENU DE L'OBJET DE NOTIFICATION*/ DTAARA(GAYTE/NOTIF) RTNVAR(&INFO) *NE ' ') DO &NOM %SST(&INFO 1 10) &JOB %SST(&INFO 11 10) &NOFAC %SST(&INFO 21 6)
/*AFFICHAGE DES INFORMATIONS DE NOTIFICATION*/ SNDRCVF RCDFMT(FMTNOTIF) IF &IN03 GOTO FIN /*REMISE A BLANC DE LA DTAARA*/ CHGDTAARA GAYTE/NOTIF ' ' ENDDO /*DEMARRAGE DU CONTROLE DE VALIDATION*/ STRCMTCTL LCKLVL(*ALL) NFYOBJ(NOTIF *DTAARA) /*EXTRACTION DES DONNEES DE L'ENVIRONNEMENT*/ RTVJOBA JOB(&JOB) USER(&NOM) /*APPEL DU PGM DE GESTION DES DONNEES*/ CALL RPG1 PARM(&NOM &JOB) MONMSG MSGID(RPG0000) EXEC(ROLLBACK) ENDCMTCTL FIN: ENDPGM
Oprations effectues pour prparer lenvironnement La journalisation doit tre dmarre pour les fichiers physiques et la zone de donnes doit exister :
CRTJRNRCV JRNRCV(NOTIF) CRTJRN JRN(NOTIF) JRNRCV(NOTIF) STRJRNPF FILE(ENTETE DETAIL) JRN(NOTIF) IMAGES(*BOTH) CRTDTAARA DTAARA(NOTIF) TYPE(*CHAR) LEN(26)
158
Source du programme de saisie des factures en RPG/400 (RPG1) Pour chaque facture, lutilisateur doit saisir un enregistrement du fichier ENTETE et un nombre variable denregistrements du fichier DETAIL. F3 permet de passer la facture suivante avec validation de la saisie et F12 provoque une invalidation. NOTIF est une data-structure qui contient les donnes associes lobjet de notification. Ce programme reoit en paramtre les noms de lutilisateur et du travail.
FDETAIL O E DISK KCOMIT FENTETE O E DISK KCOMIT FFACT CF E WORKSTN F* INOTIF DS I 1 10 NOMNTF I 11 20 JOBNTF I 21 26 FACNTF C*RECEPTION DES PARAMETRES C *ENTRY PLIST C PARM NOM 10 C PARM JOB 10 C*INITIALISATION DES VARIABLES POUR NOTIFICATION C MOVE NOM NOMNTF C MOVE JOB JOBNTF C*SAISIE D'UNE NOUVELLE FACTURE C SAISIE TAG C WRITECDE C EXFMTFMTENT C *IN03 CABEQ'1' FIN C*ECRITURE DU FORMAT ENTETE C WRITEFMT1 C MOVE NUMFAC FACNTF C*BOUCLE DE LECTURE DES LIGNES DETAIL C DO *HIVAL C EXFMTFMTDET C*SI F12 ANNULATION DEMANDEE = ROLLBACK C *IN12 IFEQ '1' C ROLBK C LEAVE C ENDIF C*SI F03 FIN NORMALE = COMMIT C *IN03 IFEQ '1' C NOTIF COMIT C LEAVE C ENDIF C*SINON ECRITURE DANS LE FICHIER C WRITEFMT2 C ENDDO C*RENVOI VERS UNE NOUVELLE FACTURE C GOTO SAISIE C*TRAITEMENT DE FIN DE FICHIER C FIN TAG A A
159
MOVE *ON
*INLR
DDS du fichier daffichage FACT Ce fichier daffichage permet la saisie des donnes de chaque facture. Il est appel par le programme RPG1.
DSPSIZ(24 80 *DS3) CA03(03) CA12(12) R FMTENT OVERLAY 1 32'SAISIE DE FACTURE' COLOR(WHT) 4 4'Code facture:' 4 19 4 33'Code client:' 4 47 4 57'Date:' 4 63 PROTECT OVERLAY 9 4'Code article:' 9 19 9 34'Quantit:' 9 45 9 55'Prix unit:' 9 65 23 3'F3=Fin F12=Annulation de la saisie' COLOR(BLU)
NUMFAC NUMCLI DATE R FMTDET
6 5 6
I I 0I
NUMART QTE PRIXU R CDE
5 6 5
I 1I 2I
Exemple 5.3 : mise en uvre du contrle de validation sappuyant sur un objet de notification. Cette application est lancer en appelant le programme NOTIF.
Remarques
Lobjet de notification doit avoir des droits publics suffisants pour que nimporte quel utilisateur effectuant de la saisie travers le programme sous contrle de validation puisse lutiliser. La valeur *CHANGE pour ces droits est un minimum. Si larrt anormal du travail se produit lors de la saisie de la premire transaction, le systme ne place aucune information dans lobjet de notification car il ne trouve aucun commit antrieur pour ce travail. Lutilisateur ne sera donc pas inform que cette transaction a t invalide. Pour viter ce dsagrment, on place au dbut du programme de traitement des donnes un commit associ une structure de donnes initialise avec une valeur spciale. Si cette valeur est contenue dans
160
lobjet de notification, il faut informer lutilisateur quaucune donne na t valide lors de sa dernire saisie (exemple 5.4).
... I I '999999' 21 26 FACNT C *ENTRY PLIST C PARM NOM 10 C PARM JOB 10 C*INITIALISATION DES VARIABLES POUR NOTIFICATION C MOVE NOM NOMNTF C MOVE JOB JOBNTF C NOTIF COMIT C* C*SAISIE D'UNE NOUVELLE FACTURE C SAISIE TAG C WRITECDE C... Exemple 5.4: ajout dun commit lexemple 5.3 pour grer linvalidation de la premire transaction. Les lignes en gras sont celles qui sont modifies ou ajoutes. Le programme traitant lobjet de notification devra tester si le numro de facture est gal 999999. Dans ce cas, il doit informer lutilisateur quaucune transaction na t valide lors de la dernire saisie.
Les journaux
Le contrle de validation sappuie sur la journalisation des fichiers physiques. Celle-ci place dans les journaux des postes de code C et dont le type dpend de lopration effectue. Lannexe B dcrit ces diffrents postes. La figure 5.9 prsente les informations de journalisation lies au programme de lexemple 5.4. La premire partie est gnre par une invalidation automatique, la seconde correspond une transaction valide. Cette information est donne par la commande DSPJRN. Postes gnrs par une invalidation automatique
N Code 360 F 362 C 363 F 364 C 365 C 366 C 367 R 368 R 369 F 370 F Type OP BC OP SC CM SC PT PT CL CL Fichier ENTETE DETAIL Utilisateur Travail GAYTE ECRAN1 ECRAN1 GAYTE ECRAN1 ECRAN1 ECRAN1 ECRAN1 GAYTE ECRAN1 GAYTE ECRAN1 GAYTE ECRAN1 GAYTE ECRAN1 Heure 10:03:18 10:03:18 10:03:19 10:03:19 10:03:19 10:03:24 10:03:24 10:03:27 10:03:33 10:03:33
ENTETE DETAIL ENTETE DETAIL
161
372 374 375 376
R R C C
DR DR RB EC
DETAIL ENTETE
GAYTE GAYTE
ECRAN1 ECRAN1 ECRAN1 ECRAN1
10:03:41 10:03:41 10:03:42 10:03:42
Postes gnrs par une transaction valide

N Code 378 F 380 C 381 F 382 C 383 C 384 C 385 R 386 R 387 R 388 C 389 F 390 F 391 C Type OP BC OP SC CM SC PT PT PT CM CL CL EC Fichier ENTETE DETAIL Utilisateur Travail GAYTE ECRAN1 ECRAN1 GAYTE ECRAN1 ECRAN1 ECRAN1 ECRAN1 GAYTE ECRAN1 GAYTE ECRAN1 GAYTE ECRAN1 ECRAN1 GAYTE ECRAN1 GAYTE ECRAN1 ECRAN1 Heure 10:35:49 10:35:50 10:35:50 10:35:50 10:35:50 10:35:55 10:35:55 10:35:58 10:36:02 10:36:03 10:36:08 10:36:09 10:36:09
ENTETE DETAIL DETAIL ENTETE DETAIL
Figure 5.9 : postes gnrs par le contrle de validation de lexemple 5.3. Les quatre premiers postes correspondent louverture des fichiers et au dmarrage du contrle de validation. Les postes 365 et 383 ont t gnrs par le commit dcrit dans lexemple 5.4. Un enregistrement du fichier ENTETE puis des enregistrements du ficher DETAIL sont crits. Les fichiers sont ferms soit aprs un commit (poste 388) soit par une fin anormale du travail. Une invalidation est alors mise (postes 372 375). Le contrle de validation peut alors se terminer (poste de type EC).
Le contrle de validation deux phases

Le contrle de validation deux phases (ou two phases commit) permet dassurer lintgrit des transactions dans un environnement de bases de donnes rparties. Il est possible depuis la V3R1M0 de lOS/400 (avant, une transaction ne pouvait tre cheval sur plusieurs systmes). Dans un programme, il est maintenant possible de mettre jour des enregistrements dans diffrentes bases de donnes et deffectuer une validation (ou une invalidation) sur lensemble de cette transaction. Le contrle de validation est plus complexe que ce que nous avons dcrit jusque-l car il faut tre sr que la validation a bien t effectue dans toutes les bases de donnes. Entre le systme client (celui qui fait tourner le programme) et les systmes serveurs (ceux qui hbergent les donnes), sinstaure une conversation en deux tapes. Dans un premier temps, le client demande chaque serveur sil est en mesure deffectuer lopration. Ce dernier crit et verrouille alors les enregistrements, puis rpond.
162
Si une impossibilit est dtecte sur un systme, un rollback gnral est mis. Sinon, quand toutes les modifications ont t ralises, le systme client demande un commit. Un second message est alors envoy chaque serveur pour les informer de la validation. Ces derniers librent les enregistrements verrouills et renvoient une confirmation. Le contrle de validation deux phases est scuris. Si un systme sarrte ou si une ligne de communication est coupe, lintgrit de la transaction sera assure soit par lmission dune invalidation gnrale (dans le cas o lincident se produit avant le commit du client), soit par la prise en compte des oprations effectues mais non encore valides. Cette fonction est supporte par DDM et par SQL. DDM peut tre utilis dans le cas o les changes ont lieu entre AS/400. SQL permet daccder aux bases de donnes de DRDA (larchitecture de bases de donnes rpartie), par exemple DB2/6000 sur Risc/6000, DB2/2 sous OS/2, DB2 sous MVS... Au chapitre consacr ce langage, nous verrons comment intgrer des requtes SQL dans des programmes RPG.
Conclusions sur le contrle de validation

Le contrle de validation est le seul moyen dassurer lintgrit des transactions. Il est assez facile mettre en uvre dans les programmes condition davoir bien dfini les frontires de transaction lors de lanalyse. Mais il est ncessaire de dmarrer la journalisation des fichiers concerns...
Les contraintes dintgrit rfrentielle

Introduction Principes
Dans une base de donnes relationnelle, on est souvent amen tablir des contraintes entre des zones de diffrents fichiers. Par exemple, le numro de client de chaque enregistrement du fichier FACTURE doit correspondre un numro de client du fichier CLIENT. Cette valeur permet de faire une jointure (fichier logique joint) ou un accs direct sur cl pour rcuprer le nom et ladresse du client pour chaque facture.
163
Traditionnellement, une telle contrainte est implmente dans les programmes. Lors de la saisie de la facture, une recherche indexe (CHAIN en RPG) est effectue sur le fichier CLIENT afin de vrifier si ce client existe bien. En cas dchec de cette requte, une nouvelle saisie (ou ventuellement une cration de client) est propose lutilisateur. Depuis la version V3R1M0 de lOS/400, ce contrle peut tre automatis grce aux contraintes dintgrit rfrentielle (que je nommerai parfois CIR). Le principe de base est extrmement simple : une (ou plusieurs) zone(s) dun fichier dpendant est mise en relation avec une (ou plusieurs) zone(s) dun fichier parent. Dans notre exemple, le fichier dpendant est FACTURE, le parent est CLIENT (figure 5.10). A chaque tentative dcriture dun enregistrement dans le fichier FACTURE, le systme vrifie automatiquement si le contenu de la zone NUMCLI correspond une valeur de NOCLI du fichier CLIENT. En cas de succs, la mise jour est effectue et le programme continue son droulement. En cas dchec, un message derreur de type *ESCAPE est renvoy au programme. Ce message doit tre intercept sinon il remonte lutilisateur par lintermdiaire de la file dattente externe.
CLIENT (parent)
NOCLI
FACTURE (dpendant)
NUMCLI
25 50 200
50 200 50 25
Figure 5.10 : contrainte dintgrit rfrentielle entre deux fichiers.
La dpendance, comme nous venons de le voir, fonctionne dans le sens fichier dpendant vers fichier parent mais elle est aussi active dans lautre sens. Un client ne pourra tre dtruit sil a encore une facture en cours. Autrement dit, on ne peut supprimer un enregistrement dun fichier parent sil est en relation avec un enregistrement du fichier dpendant.
Les chemins daccs
164
Pour effectuer rapidement les recherches, le systme sappuie sur des chemins daccs. Ces structures doivent donc tre cres pour chacun des deux fichiers si elles nexistent pas dj. Le chemin daccs du fichier parent possde les caractristiques particulires suivantes : il est unique. Il ne peut y avoir deux enregistrements du fichier parent qui ont mme valeur de cl. Dans notre exemple, deux clients ne pourront avoir le mme numro ; sous certaines conditions, il peut tre cr automatiquement par le systme lors de ltablissement de la contrainte. Si ces conditions ne sont pas remplies, il faut le gnrer laide dune commande. Nous y reviendrons ; si ce chemin daccs existe dj et sil a t dfini avec le mot-cl UNIQUE, il sera partag.
Mise en uvre
La commande ADDPFCST (add physical file constraint) permet de mettre en place une CIR (figure 5.11).
Ajouter contrainte fich phys (ADDPFCST) Indiquez vos choix, puis appuyez sur ENTREE. Fichier . . . . . . . . . . . . FILE > FACTURE Bibliothque . . . . . . . . . *LIBL Type de contrainte . . . . . . . TYPE > *REFCST Cl de la contrainte . . . . . . KEY > NOCLI + si autres valeurs Nom de la contrainte . . . . . . CST *GEN
Fichier parent . . . . . . . Bibliothque . . . . . . . Cl parente . . . . . . . . + si Rgle de suppression . . . . Rgle de mise jour . . . .
. . PRNFILE . . . . PRNKEY autres valeurs . . DLTRULE . . UPDRULE
> CLIENT *LIBL > NUMCLI *NOACTION *NOACTION Fin
F3=Exit F4=Invite F5=Rafficher F12=Annuler F13=Mode d'emploi invite F24=Autres touches
Figure 5.11 : cran de la commande ADDPFCST avec TYPE(*REFCST).
Voici les caractristiques TYPE(*REFCST)):
des
paramtres
de
cette
commande
(avec
165
FILE : dfinit le nom du fichier dpendant ; TYPE : dans ce contexte doit avoir la valeur TYPE(*REFCST) (tablissement dune CIR) ; KEY : permet de donner la liste des zones du fichier dpendant qui vont composer la cl ; CST : prcise le nom de la contrainte. Le systme propose de le gnrer automatiquement ; PRNFILE : indique le nom du fichier parent ; PRNKEY : permet de donner la liste des zones du fichier parent qui vont composer la cl. Ces zones doivent tre compatibles une une avec celles qui composent la cl du fichier dpendant ; DLTRULE : prcise laction entreprise par le systme lors dune tentative de suppression dun enregistrement du fichier parent : *NOACTION : lenregistrement est dtruit sil nexiste pas un enregistrement du fichier dpendant qui lui est associ (mme valeur de cl). Le programme dclencheur associ lvnement *AFTER-*DELETE (aprs suppression) est lanc, sil a t dfini, mme si la suppression a choue, *RESTRICT : lenregistrement est dtruit sil nexiste pas un enregistrement du fichier dpendant qui lui est associ (mme valeur de cl). Le programme dclencheur associ lvnement *AFTER-*DELETE (aprs suppression) nest pas lanc, *CASCADE : tous les enregistrements du fichier dpendant qui sont associs lenregistrement du fichier parent seront dtruits avec lui. Dans notre exemple, si lon supprime un client, toutes ses factures seront dtruites avec lui. Il est important de procder avec attention car si le fichier dpendant est lui mme parent avec DLTRULE(*CASCADE) pour une autre contrainte, cela peut provoquer des destructions en chane dsastreuses, *SETDFT : lenregistrement du fichier parent est dtruit et les cls associes du fichier dpendant prennent les valeurs par dfaut, *SETNULL : lenregistrement du fichier parent est dtruit et les cls associes du fichier dpendant prennent la valeur indfinie. Il faut que cela soit permis au niveau des DDS de ce fichier ;
166
UPDRULE : prcise laction effectuer par le systme en cas de mise jour dun enregistrement du fichier parent : *NOACTION : le programme dclencheur associ lvnement *AFTER*UPDATE est lanc. Il ny a pas de mise jour sil y a des enregistrements du fichier dpendant en relation avec lenregistrement du fichier parent modifier, *RESTRICT : aucune modification de lenregistrement du fichier parent nest possible sil y a une dpendance. Le programme associ lvnement *AFTER-*UPDATE nest pas lanc. Si tout se passe bien, la CIR est tablie immdiatement, sinon un message derreur (gnralement CPF32B0), plac dans lhistorique du travail, donne des indications claires sur les causes de lchec. Voici les principales : le fichier est endommag ; le fichier ne peut pas contenir plus d'un membre ; le fichier doit tre un fichier description externe ; une contrainte de cl primaire existe dj ; une contrainte unique duplique existe. Il faut enfin noter quelques limitations aux contraintes dintgrits rfrentielles : seuls les fichiers physiques peuvent participer aux contraintes dintgrit rfrentielles ; les CIR ne peuvent stablir sur des fichiers multimembres. Le seul fait davoir MAXMBR suprieur 1 suffit faire chouer toute tentative.
Lordre SQL ALTER TABLE permet aussi de dfinir une contrainte dintgrit rfrentielle.
Les cls
Avec cette fonction est apparue une nouvelle distinction dans la notion de cl.
167
Le premier chemin daccs cr pour un fichier physique est considr comme primaire. Cette distinction est importante car le systme nest capable de crer automatiquement que des chemins daccs primaires. Ainsi, la commande ADDPFCST que nous venons de dcrire ci-dessus (avec TYPE(*REFCST)), ne gnrera le chemin daccs du fichier parent que si cest le premier. Sinon, il faudra le faire laide de la commande ADDPFCST mais avec, cette fois, les paramtres suivants : FILE : qui est le nom du fichier parent ; TYPE : qui doit avoir pour valeur TYPE(*UNQCST) pour crer un chemin daccs unique. Eventuellement, la valeur TYPE(*PRIKEY) permet de crer un chemin daccs primaire, le systme tant capable de le faire tout seul ; KEY : qui reprsente la liste des zones qui composent la cl ; CST : qui est le nom de la contrainte. Pour la cration automatique du chemin daccs du fichier parent par la commande ADDPFCST TYPE(*REFCST) plusieurs cas peuvent se prsenter : si le chemin daccs est dj cr et sil est unique il y aura partage de la structure existante ; sil nest pas unique, il ne peut y avoir partage. Il existe alors deux solutions. La premire consiste crer un nouveau chemin daccs de type *UNQCST. Il y aura alors deux chemins daccs maintenir. La seconde consiste recrer lancien en lui ajoutant lunicit. Cette solution peut tre parfois lourde surtout si le chemin daccs est codifi dans les DDS du fichier physique (au niveau Cl) car il faut recompiler le fichier, donc le dtruire au pralable avec tout ce que cela implique ; si le chemin daccs nexiste pas, il sera automatiquement cr sil est le premier, sinon il faudra utiliser la commande ADDPFCST TYPE(*UNQCST). La figure 5.12 rsume ces situations. Notons quil ny a aucun problme de cet ordre pour le fichier dpendant, le chemin daccs ntant pas unique.
168
Le chemin daccs existe-t-il ? OUI Est-il unique ? NON OUI Echec ! Il faut recrer un chemin daccs unique (*UNQCST) OUI NON Est-ce le premier ?
Partage du chemin existant
Cration automatique
Figure 5.12 : la cration des chemins daccs et la commande ADDPFCST.
La gestion
La commande WRKPFCST permet de grer les CIR (figure 5.13). Sur lcran affich on peut visualiser les contraintes dintgrit rfrentielle (de type *REFCST), les cls primaires (*PRIKEY) et les chemins daccs uniques (*UNQCST). Loption 2, ou la commande CHGPFCST STATE(*DISABLED), permettent de dsactiver momentanment une CIR. Le responsable des donnes peut ainsi faire le mnage dans les fichiers, notamment modifier ou supprimer des enregistrements du fichier parent. Une fois ce bricolage termin, loption 6 en regard de la contrainte concerne nous permet de vrifier si tout est cohrent. Cette option affiche les enregistrements du fichier dpendant qui ne correspondent pas la CIR. Sils existent, il faudra les supprimer avant de rtablir la contrainte. Cette dernire opration est effectue avec loption 2, ou la commande CHGPFCST, mais cette fois avec la valeur STATE(*ENABLED).
Gestion des contraintes de fichier physique Indiquez vos options, puis appuyez sur ENTREE. 2=Modifier 4=Enlever 6=Afficher enreg en instance de vrif Vrification en Etat instance ETB/ACT NON ETB/DES OUI
Opt
Contrainte NUMCLI NOMCLI QSYS_PAREN CLE_NOMCLI
> > > >
Fichier DEPENDANT DEPENDANT2 PARENT PARENT
Biblio V310 V310 V310 V310
Type *REFCST *REFCST *PRIKEY *UNQCST
169
Fin Paramtres pour les options 2, 4, 6 ou commande ===> F3=Exit F4=Invite F5=Rafficher F12=Annuler F15=Trier F16=Repositionner F17=A partir de F22=Nom de contrainte
Figure 5.13 : cran de la commande WRKPFCST.
La commande RMVPFCST, et loption 4 de la commande WRKPFCST, permettent de dtruire une contrainte. La visualisation de la partie descriptive dun fichier par DSPFD montre les contraintes dintgrit auxquelles le fichier est soumis. Les droits *OBJREF sur un fichier sont ncessaires pour pouvoir grer ses CIR.
La journalisation
La journalisation des fichiers physiques participants aux contraintes dintgrit rfrentielle est obligatoire sauf : si les rgles de modification et de suppression des enregistrements du fichier parent sont DLTRULE(*RESTRICT) et UPDRULE(*RESTRICT) ; si aucune action (modification, suppression) nest intente sur les enregistrements du fichier parent. DFU, par exemple ne peut tre lanc pour modifier un fichier parent sil nest pas journalis. En fait, la journalisation doit tre considre comme indispensable. Le systme se sert de ces journaux et place ses propres postes pour le contrle de validation quil met automatiquement en place. Il reste noter que les deux fichiers (parent et dpendant) doivent utiliser le mme journal.
Exemple en RPG
Lutilisation des CIR allge la programmation car elle enlve bon nombre de contrles. Pour bien faire, il faut toutefois intercepter les ventuels messages derreurs renvoys par le systme et informer lutilisateur. En RPG, tout message
170
derreur est traduit par lexcitation de lindicateur associ lordre dentre/sortie (WRITE, UPDAT). Si cet indicateur est en fonction cest que lcriture na pu tre ralise. On peut alors imputer cet chec la CIR, mais cela est un peu simpliste car il peut y avoir dautres causes (notamment les dclencheurs). Il faut donc rcuprer le message reu par le programme et le traiter. En fonction de son identification, on sait quel est lvnement qui a empch lcriture. La CIR renvoie le message CPF502D pour une tentative dinsertion dun enregistrement dans le fichier dpendant qui na pas de correspondance dans le fichier parent. Le message CPF503A est mis lors dune tentative infructueuse de suppression dun enregistrement du fichier parent. En RPG, un message derreur peut tre rcupr au moins de deux manires : par lINFDS et par les API. Ces deux possibilits sont prsentes dans lexemple 5.6. DDS du fichier physique dpendant
R FMT NOCLI MONTNT DATE 5 7 6
DDS du fichier physique parent

R FMTP NOCLI NOMCLI ADRESSE 5 15 20
DDS du fichier daffichage SAISIE

DSPSIZ(24 80 *DS3) CA03(03) R FMT1 1 30'SAISIE DES REGLEMENTS' COLOR(WHT) 5 3'Numro du client:' 5 37'Montant:' 5 61'Date:' I 5 21 ERRMSG('Ce client n''existe + pas' 52) 2I 5 47 I 5 67
NOCLI 52 MONTNT DATE
7 6
Source du programme RPG utilisant lINFDS

FREGLMT FSAISIE IDATA O CF E E DS K DISK WORKSTN KINFDS DATA
171
I *
46
52 IDMSG
C DO *HIVAL C EXFMTFMT1 C *IN03 IFEQ '1' C LEAVE C ENDIF C WRITEFMT 90 C *IN90 IFEQ '1' C EXSR ERREUR C ENDIF C ENDDO C MOVE *ON *INLR C* C************SOUS ROUTINE ERREUR************************ C ERREUR BEGSR C IDMSG IFEQ 'CPF502D' C*LE CLIENT N'EXISTE PAS C MOVE *ON *IN52 C ENDIF C*PROCEDER AINSI POUR TOUS LES MESSAGES POSSIBLES: C* IDMSG IFEQ 'CPF503A' C*IMPOSSIBLE DE SUPPRIMER CE CLIENT C* MOVE *ON *IN53 C* ENDIF C ENDSR
Source du programme RPG/400 utilisant une API

FREGLMT O E K DISK FSAISIE CF E WORKSTN IINFO DS I 13 19 IDMSG IERR DS I I 00 B 1 40LGERR I* I*AUCUNE GESTION DES ERREURS DE LAPI ! C* C DO *HIVAL C EXFMTFMT1 C *IN03 IFEQ '1' C LEAVE C ENDIF C WRITEFMT 90 C *IN90 IFEQ '1' C EXSR ERREUR C ENDIF C ENDDO C MOVE *ON *INLR C* C************SOUS ROUTINE ERREUR************************ C* C*EXTRACTION DU MESSAGE PAR API C ERREUR BEGSR C CALL 'QMHRCVPM'
172
C PARM INFO C PARM X'19' LG 4 C PARM 'RCVM0100'FMTRCV 8 C PARM '*' PGMQ 10 C PARM X'00' STK 4 C PARM '*LAST' TYPE 10 C PARM CLE 4 C PARM X'00' TIME 4 C PARM '*SAME' ACTION 10 C PARM ERR C*LE TRAITEMENT EST LE MME QUE PRECEDEMMENT C IDMSG IFEQ 'CPF502D' C*LE CLIENT N'EXISTE PAS C MOVE *ON *IN52 C ENDIF C*PROCEDER AINSI POUR TOUS LES MESSAGES POSSIBLES C* IDMSG IFEQ 'CPF503A' C*IMPOSSIBLE DE SUPPRIMER CE CLIENT C* MOVE *ON *IN53 C* ENDIF C ENDSR
Exemple 5.6 : programme RPG/400 sappuyant sur une contrainte dintgrit rfrentielle en utilisant soit lINFDS, soit une API.
173
Conclusions
Cette fonction tait trs attendue et son absence tait considre comme une fcheuse lacune de la base de donnes de lAS/400. Avec la version V3R1M0 de lOS/400 elle apparat comme fondamentale. Sa mise en uvre est extrmement simple et ses performances semblent excellentes car elle nest pas active travers des programmes dclencheurs, comme sur certains SGBD, mais directement par des fonctions systme. Elle doit surtout tre utilise pour les nouvelles applications. Il est en effet inutile de limplmenter pour des fichiers attaqus par des programmes qui effectuent eux-mmes les contrles. Il y aurait alors double traitement, ce qui est inutile. Ce qui est important cest quune fois mise en place, elle est incontournable. Il faut considrer quelle est au niveau des donnes. Que ce soit avec DFU, par du client/serveur, avec des applications classiques en RPG ou Cobol, ou mme au travers de DRDA (larchitecture de base de donnes rparties dIBM), la CIR est toujours active. Elle fait partie intgrante du fichier et elle est sauvegarde avec lui. Lors de la restauration elle sera automatiquement active si cela est possible. Il est donc prfrable de toujours restaurer un fichier parent avant ses dpendants. Enfin, la commande CRTDUPOBJ recopie les contraintes dintgrit dun fichier dpendant dans le nouvel objet qui sera donc associ au mme parent. Tous ces mcanismes assurent une parfaite intgrit de la base de donnes. La contrainte gre ici est une galit entre le contenu de deux zones, ou de deux sries de zones. Pour des contraintes plus complexes on peut utiliser ses propres programmes de validation par lintermdiaire des dclencheurs.
Les dclencheurs (triggers)

Depuis la version V3R1M0 de lOS/400, on peut associer un programme un vnement li la base de donnes. Si cet vnement se produit, ce programme dit dclencheur (ou trigger en anglais) est automatiquement lanc. Cette nouvelle fonction ouvre de nouveaux horizons, quasiment illimits. Les dclencheurs sont associs aux fichiers physiques. Ds que lvnement correspondant se produit, le programme est lanc quel que soit lorigine de cet vnement. On peut ainsi placer juste au dessus des donnes une couche logicielle qui devra tre obligatoirement traverse pour accder aux enregistrements.
174
Les dclencheurs existent dans dautres bases de donnes o ils sont parfois cods avec un langage spcial propre cette fonction. Pour lOS/400, le programme est nimporte quel objet de type *PGM (RPG IV, RPG/400, CLP, Cobol...) ou mme une procdure Rexx, et cest une excellente chose. Il ny a pas de nouveau langage apprhender. Pour un fichier, six vnements permettent le dclenchement et peuvent chacun tre associs un programme. Ce sont : *BEFORE-*INSERT : avant insertion ; *AFTER-*INSERT : aprs insertion ; *BEFORE-*UPDATE : avant modification ; *AFTER-*UPDATE : aprs modification ; *BEFORE-*DELETE : avant suppression ; *AFTER-*DELETE : aprs suppression.
Mise en uvre
La commande ADDPFTRG permet, pour un fichier physique, de lier un programme un vnement. La syntaxe est simple, les paramtres sont les suivants : FILE : nom du fichier (seuls les fichiers physiques peuvent tre associs des dclencheurs) ; TRGTIME : moment par rapport laction de dclenchement, soit avant (*BEFORE) soit aprs (*AFTER) ; TRGEVENT : action qui dclenche lvnement. Les valeurs peuvent tre : *INSERT : insertion ; *DELETE : destruction ; *UPDATE : modification ; PGM : nom et bibliothque du programme appeler si cet vnement survient ; RPLTRG : action entreprendre si un dclencheur est dj dfini pour cet vnement. Si la valeur est *YES lancien programme est remplac par le nouveau, sinon aucune modification nest effectue pour ce dclencheur ;
175
TRGUPDCND : indique le comportement du dclencheur lors de la mise jour dun enregistrement avec des valeurs identiques. Le programme est lanc si sa valeur est *ALWAYS. Ainsi, la commande pour associer le programme TRG de la bibliothque BIB lvnement avant insertion pour le fichier FICH est :
ADDPFTRG FILE(FICH) TRGTIME(*BEFORE) TRGEVENT(*INSERT) PGM(BIB/TRG)
Il est prfrable de qualifier le nom du programme car nimporte quel travail peut dclencher cet vnement et il nest pas vident quil ait la bonne bibliothque dans sa liste de bibliothque. Les droits *OBJALTER sur un fichier sont indispensables pour agir sur ses dclencheurs. Si la mise en uvre de cette fonction est extrmement simple au niveau du fichier, la codification du programme associ est, par contre, un peu plus complexe.
Le programme dclencheur
Le programme dclencheur doit respecter certaines rgles au niveau des paramtres quil reoit et au niveau de linformation retourner au programme appelant en cas de problme.
Les paramtres
Lorsquil est appel, le programme dclencheur reoit deux paramtres. Le premier est une structure contenant toutes les informations sur lopration en cours, y compris les images de lenregistrement tel quil tait avant et tel quil sera aprs cette opration sil y a lieu. Le tableau suivant dcrit les principaux lments de cette structure (les informations concernant les zones valeur indfinies (NULL) ont t omises) :
Offset 0 10 20 30 31 32 36 48 Type CHAR CHAR CHAR CHAR CHAR CHAR BIN BIN Lg 10 10 10 1 1 1 4 4 Description Nom du fichier Nom de la bibliothque Nom du membre Type dopration : 1 = insertion ; 2 = destruction ; 3 = modification Moment par rapport lopration : 1 = aprs ; 2 = avant Type de verrouillage : de 0 = *NONE 3 = *ALL CCSID Offset de limage avant
176
52 64 68 * *
BIN BIN BIN
4 Longueur de limage avant 4 Offset de limage aprs 4 Longueur de limage aprs Image avant Image aprs
Voici quelques principes qui permettent de grer correctement ces informations : loffset indiqu pour une zone peut tre dfini comme le nombre de caractres qui sont devant cette zone. Ainsi, le nom du membre qui a un offset de 20 commence la position 21 car il y a vingt caractres devant ; pour extraire limage avant, on doit procder en deux tapes : tout dabord, il faut extraire le contenu de la zone situe en position 53 (offset 52) sur une longueur de 4. Le rsultat est un nombre binaire quil faut convertir en Dcimal condens, et qui contient loffset de limage avant. En lui ajoutant 1, on obtient la position du premier caractre de cet enregistrement, il suffit alors daller la position ainsi calcule pour extraire les donnes de lenregistrement tel quil tait avant lopration. Sa longueur est donne par la zone doffset 52, toujours en binaire de longueur 4. On procdera de la mme manire pour extraire limage aprs ; ce mode de positionnement (offset, donnes en binaire) est caractristique des fonctions avances de lOS/400. Elles sont couramment utilises avec les API systme ; limage avant est renseigne dans les cas de suppression et de modification, limage aprs est valide lors dun ajout ou dune modification. Le second paramtre indique la longueur valide du premier paramtre dans une variable binaire de longueur 2. Les informations contenues dans ces deux paramtres permettent dcrire des programmes gnriques qui fonctionnent avec nimporte quel fichier.
Les traitements
Le programme dclencheur peut effectuer nimporte quel traitement (mise jour dautres fichiers et mme du fichier en cours) condition de ne pas modifier lODP du programme appelant. Il ne faut donc pas partager le mme ODP que ce programme.
177
Il est fortement dconseill de faire du contrle de validation dans les programmes dclencheurs. En effet, le programme appelant utilise peut-tre cette fonction et lappel dun commit ou dun rollback dans le dclencheur provoquerait une interfrence entre les deux cycles de validation, ce qui pourrait avoir de fcheuses rpercussions.
Le message de type *ESCAPE

Le programme dclencheur peut servir vrifier si une action sur un fichier physique est autorise. Si tout se passe bien, il doit se terminer normalement, sinon il doit renvoyer au programme appelant une information lui signifiant que lopration a choue. Cette information est un message de type *ESCAPE qui provoque larrt de lopration sur les donnes. Le programme appelant qui reoit ce message doit lintercepter et le traiter la manire de ce que nous avons vu pour les contraintes dintgrit rfrentielles (exemple 5.6). Sinon, le message CPF502B est mis destination de lutilisateur via la file dattente externe. Lidentification du message de type *ESCAPE na aucune importance pour le systme. Cest le type qui est important car il provoque un arrt. On choisira donc un message clair car il figurera dans lhistorique du travail. Jutilise couramment les messages CPF9897 et CPF9898 du fichier de message QCPFMSG de QSYS car ils permettent de placer le texte que lon dsire dans un message prenregistr, ce type de message tant obligatoire pour lenvoi dun message *ESCAPE par la commande SNDPGMMSG. CPF9898 se distingue de CPF9897 par la prsence dun point. Larchitecture dun programme dclencheur est reprsent dans lexemple 5.7.
PGM PARM(&VAR &LG)
DCL &VAR *CHAR 200 /*La longueur de la variable dpend de la taille de + lenregistrement*/ DCL &LG *CHAR 2 /*Extraction des informations reues en paramtres*/ CHGVAR ..... CHGVAR ..... /*Si problme envoi du message*/ IF COND(.....) THEN(DO) SNDPGMMSG MSGID(CPF9897) MSGF(QCPFMSG) + MSGDTA('Erreur dclencheur !') MSGTYPE(*ESCAPE)
178
GOTO FIN ENDDO ELSE DO /*Tout est correct*/ .../*Traitement des donnes*/ ENDDO FIN: /*Traitements de fin*/ ENDPGM
Exemple 5.7 : structure dun programme dclencheur. Le langage de contrle est choisi pour sa lisibilit.
La codification de lenvoi de message est relativement simple en langage de contrle (grce la commande SNDPGMMSG) mais ncessite lemploi des API en RPG. Nous allons maintenant prsenter des exemples complets dans chacun de ces deux langages. Ils peuvent tre facilement tests avec DFU.
Exemple en langage de contrle

Le programme dcrit dans lexemple 5.8 extrait une partie des donnes dun enregistrement supprimer et demande une confirmation lutilisateur par lintermdiaire de la file dattente externe. Il na probablement pas grand intrt dans le cadre dune exploitation mais montre assez simplement comment fonctionne un dclencheur. Il est associer au fichier FICH et lvnement avant suppression. Commande de dfinition du dclencheur
ADDPFTRG FILE(FICH) TRGTIME(*BEFORE) TRGEVENT(*DELETE) PGM(TRG)
Source du programme en langage de contrle TRG

PGM DCL DCL DCL DCL DCL DCL PARM(&VAR &LG) &VAR *CHAR 150 &LG *CHAR 2 &REP *CHAR 1 &OFSTAVT *DEC (5 0) &NOCLI *CHAR 5 &MSG *CHAR 80
/*Extraction de l'offset de l'image avant en dcimal*/ CHGVAR &OFSTAVT %BIN(&VAR 49 4) /*Conversion offset => position*/ CHGVAR &OFSTAVT (&OFSTAVT + 1) /*Extraction de la zone NOCLI sur 5 caractres*/ CHGVAR &NOCLI %SST(&VAR &OFSTAVT 5) /*Envoi du message dans la file d'attente externe*/ SNDUSRMSG MSGID(CPF9897) MSGF(QCPFMSG) MSGDTA('Voulez +
179
vous dtruire l''enregistrement ' *CAT &NOCLI *CAT ' O/N ?') + VALUES('O' 'N') DFT('N') TOMSGQ(*EXT) MSGRPY(&REP) /*Rcupration de la rponse dans &rep*/ /*Si &REP=N envoi du message d'annulation*/ CHGVAR &MSG ('Annulation utilisateur pour NOCLI = ' *CAT &NOCLI) IF COND(&REP = 'N') THEN(SNDPGMMSG + MSGID(CPF9897) MSGF(QCPFMSG) MSGDTA(&MSG) MSGTYPE(*ESCAPE)) ENDPGM
DDS du fichier FICH

R FMT NOCLI NOMCLI ADRES 5 15 20
Historique du travail supprimant les enregistrements (DSPJOBLOG)

Voulez vous dtruire l'enregistrement abcde O/N ? ? O Voulez vous dtruire l'enregistrement 12345 O/N ? ? N Annulation utilisateur pour NOCLI = 12345 Une erreur s'est produite dans le programme dclencheur. Une erreur s'est produite dans le programme dclencheur.
Exemple 5.8 : programme dclencheur et langage de contrle. A chaque suppression dun enregistrement du fichier FICH, un message est envoy lutilisateur via la file dattente externe pour lui demander une confirmation. Il peut confirmer (O) ou annuler (N) lopration. Dans lhistorique du travail prsent, lutilisateur a confirm la premire suppression et a infirm la seconde. Le texte associ au message CPF9897 est clair, il permet didentifier clairement la cause de lannulation.
Le message CPF9897 devra tre intercept par le programme appelant la manire de ce qui est dcrit pour les contraintes dintgrit rfrentielle dans lexemple 5.6. Le langage de contrle permet dcrire des programmes dclencheurs relativement simples. Il est limit car il permet difficilement dextraire des zones de type Dcimal condens dans les images avant et aprs. De plus, il ne permet pas dcrire dans les fichiers. Le RPG est bien plus appropri mais il impose lutilisation des API pour envoyer le message de type *ESCAPE.
Exemple en RPG
180
En cas de modification dun enregistrement, ce programme vrifie que la nouvelle valeur pour la zone salaire est suprieure ou gale lancienne. Il ne sera lanc que lorsque le nouvel enregistrement est diffrent de lancien. DDS du fichier FICH
R FMT CODEMP NOMEMP MNTSAL 5 15 7
181
Source du programme RPG/400 TRGRPG

*DS DECOUPANT LE PARAMETRE IENREG DS I B 49 520AVT I B 65 680APR I 69 150 FIN *DS DECOUPANT L'IMAGE AVANT IIMGAVT DS I 1 5 CDEB I 6 20 NOMB I P 21 242MNTB *DS DECOUPANT L'IMAGE APRES IIMGAPR DS I 1 5 CEMA I 6 20 NOMA I P 21 242MNTA *DS POUR DIVERSES DECLARATIONS IDIVERS DS I I 'QCPFMSG QSYS' 1 20 MSGF I I 'ANNULATION DEMANDEE' 21 39 DATA I I 0 B 40 430ERR I I 19 B 44 470LGDTA I I 1 B 48 510STCK C* C*DEFINITION DES PARAMETRES C* C *ENTRY PLIST C PARM ENREG C PARM LG 2 C* C*INITIALISATION DES VARIABLES POUR IMG AVANT ET APRES C 1 ADD AVT PAVT 50 C 1 ADD APR PAPR 50 C 24 SUBSTENREG:PAVTIMGAVT C 24 SUBSTENREG:PAPRIMGAPR C* C*TEST SI LE NOUVEAU MONTANT EST < A L'ANCIEN C MNTA IFLT MNTB C* C*SI OUI APPEL DE L'API D'ENVOI DE MESSAGE C CALL 'QMHSNDPM' C PARM 'CPF9897' MSGID 7 C PARM MSGF C PARM DATA C PARM LGDTA C PARM '*ESCAPE' TYPE 10 C PARM '*' PGMQ 10 C PARM STCK C PARM CLE 4 C PARM ERR C ENDIF C*FIN DU PROGRAMME C RETRN
182
Commande de dfinition du dclencheur

ADDPFTRG FILE(FICH) TRGTIME(*BEFORE) TRGEVENT(*UPDATE) + PGM(TRGRPG) TRGUPDCND(*CHANGE)
Historique du travail modifiant les enregistrements (DSPJOBLOG)

ANNULATION Une erreur Une erreur Le message DEMANDEE s'est produite dans le programme dclencheur. s'est produite dans le programme dclencheur. CPF502B a t mis.
Exemple 5.9 : programme dclencheur et RPG/400. Il vrifie si la nouvelle valeur de la zone MNTSAL est bien suprieure lancienne.
Remarques
Les contraintes dintgrit rfrentielle et les dclencheurs peuvent cohabiter pour le mme fichier. Le programme dclencheur sexcute dans le travail du programme appelant, avec ses autorisations et ses contraintes. Il est prudent de mettre des droits publics suffisants au dclencheur et aux diffrents objets quil gre afin que nimporte quel travail puisse lutiliser. Le dclencheur est appel chaque opration sur un fichier pour laquelle il a t dfini dans la commande ADDPFTRG. Son impact sur les performances des applications est donc direct. Il est donc essentiel de tout mettre en uvre pour quil soit optimis au maximum en suivant les rgles classiques : en RPG/400, terminer le programme par le code opration RETRN plutt que par le classique SETON LR pour diminuer le temps de chargement lors de lappel suivant. Il faut avoir lesprit que le lancement du dclencheur est un CALL dynamique ; viter les gros programmes et les interactions avec lutilisateur par lintermdiaire dun fichier daffichage (le programme appelant sera peut tre excut en batch) ; limiter au strict minimum le nombre de fichiers traiter, la cration des ODP correspondants tant trs pnalisante.
183
Les enregistrements du fichier qui est associ au dclencheur sont traits un par un. SEQONLY(*YES) permettant de grouper les oprations sur les donnes ne peut donc tre utilis.
Conclusions
La notion de dclencheur telle quelle est implmente dans lOS/400 apparat aujourdhui comme une russite. Sa mise en uvre est relativement simple et les programmes dclencheurs peuvent tre crits dans le langage de notre choix. Avec cette fonction, on peut maintenant mettre en place des contraintes dintgrit complexes, impliquant plusieurs zones et mme plusieurs fichiers, on peut raliser des espions qui garderont une trace de ce qui est modifi dans les fichiers sensibles et bien dautres choses encore. Avec les contraintes dintgrit rfrentielle, les dclencheurs forment une couche logicielle indpendante des applications quil faut obligatoirement traverser pour accder aux donnes. Ainsi, on peut facilement homogniser les contrles mme pour des environnements aussi varis que le client/serveur, la base de donnes rpartie et le local. Les dclencheurs font partie intgrante des fichiers et sont visualisables par la commande DSPFD.
La sauvegarde et la restauration
Comme pour tous les systmes, les sauvegardes sont obligatoires sur AS/400. Elles constituent le point de dpart de la reprise aprs la perte de fichiers et permettent de retrouver la base de donnes dans un tat stable et cohrent. Pour quelles soient efficaces, les sauvegardes doivent tout dabord tre rgulires et frquentes, sinon la version des fichiers restaurs risque dtre trs ancienne. Ensuite, elles doivent avoir lieu au moment o la base de donnes est dans un tat stable et cohrent afin davoir sur le support externe (bande, cartouche...) une version que lon pourra restaurer sans soucis. La sauvegarde lors de la mise jour des donnes (paramtre SAVACT) est utiliser avec prudence et si possible en arrtant la mise jour jusqu ltablissement du point de synchronisation. Il va de soi que les supports de sauvegarde doivent tre si possible rangs dans un endroit sr, labri dune catastrophe toujours possible (inondation, incendie...).
184
Les commandes qui permettent de sauvegarder les objets de la base de donnes sont les classiques SAVOBJ, SAVCHGOBJ et SAVLIB. Le paramtre ACCPTH de ces commandes prcise si les chemins daccs dun fichier physique sont sauvegards avec lui. Il faut remarquer que : seuls les chemins daccs des membres sauvegards sont pris en compte ; tous les fichiers physiques sur lesquels sappuie un fichier logique doivent tre dans la mme bibliothque mais cette dernire peut tre diffrente de celle du fichier logique ; si le fichier logique et les fichiers physiques sont dans des bibliothques diffrentes et sil manque certains de ces objets lors de la restauration, les chemins d'accs seront reconstruits et non restaurs ce qui est gnralement beaucoup plus long. Il est donc conseill de placer les fichiers physiques et les fichiers logiques dune mme application dans une seule bibliothque. Rappelons que la sauvegarde des chemins d'accs ne protge aucune donne mais permet seulement de reconstruire plus rapidement la base de donnes en cas dincident. Par dfaut, des informations sur la sauvegarde sont places dans la partie descriptive de lobjet et sont visualisables par la commande DSPOBJD. Le paramtre UPDHST(*NO) inhibe la mise jour de ces donnes.
La scurit
La scurit est une des fonctions essentielles de lOS/400. Elle fait partie intgrante de la base de donnes et elle est trs simple mettre en uvre condition davoir procd une bonne analyse des droits et des interdictions de chacun. La scurit tant traite en dtail dans louvrage Principes gnraux et langage de contrle sur AS/400 (Eyrolles, 2e dition, 1995), je ny reviendrai pas et dcrirai seulement ce qui est spcifique la base de donnes.
185
Les droits sur les fichiers sont, comme pour tout objet, scinds en deux parties : ceux qui concernent lobjet lui mme et ceux qui protgent les donnes quil contient. Au niveau de lobjet, on trouve les droits : dopration, qui permettent dutiliser cet objet et de visualiser ses attributs ; de gestion, qui dfinissent la possibilit de grer son niveau de scurit, de le dplacer ou de le copier ; dexistence, qui autorisent le contrle de son existence et le rattachement un propritaire. Les droits sur les donnes portent sur la lecture, lajout, la modification et la suppression. Pour les fichiers physiques, ils contrlent les oprations que lon peut effectuer sur les enregistrements. Les fichiers logiques nont pas proprement parler de donnes et leurs droits protgent laccs aux enregistrements des fichiers physiques. Nous avons dj signal au chapitre 4 que pour accder des enregistrements travers un fichier logique lutilisateur doit disposer des droits suffisants sur les donnes des fichiers physique et logique. Signalons que cette scurit est incontournable et quune fois mise en place nimporte quel travail doit disposer des droits ncessaires pour accder une information de DB2/400 que ce soit au travers du client/serveur ( partir de Client Access/400, par exemple), partir de DRDA ou laide de tout autre moyen. Depuis la V2R3M0 de lOS/400, la fonction daudit permet de savoir qui a utilis un objet, notamment un fichier. Elle peut tre mise en place laide des valeurs systme QAUDLVL et QAUDCTL et sappuie sur la journalisation (journal QAUDJRN de QSYS). Pour conclure sur la scurit, et pour montrer sa puissance, il faut signaler que lOS/400 peut, sous certaines conditions, rpondre la norme C2 qui est une des plus draconiennes en matire de scurit (elle a t tablie par le DOD (Departement Of Defense) des tats-Unis).
Les dispositifs matriels

Des dispositifs matriels permettent de protger la base de donnes contre la dfaillance dun disque ou dun des dispositifs qui lui sont associs (contrleur,
186
IOP, bus...). Ils sont complmentaires de la journalisation quils ne remplacent pas et ne dispensent en aucun cas deffectuer des sauvegardes. A ce jour, on peut identifier trois modes de protection matrielle : le contrle dintgrit o linformation stocke sur un disque permet de reconstruire une unit dfaillante ; le RAID 5 qui est comparable au contrle dintgrit sur le principe mais beaucoup plus efficace ; le mirroring qui consiste doubler chaque disque par une unit identique qui contient son image (disque miroir). Le dtail de ces fonctions sortant du cadre de la base de donnes, je me contenterai donc de dcrire leurs principales caractristiques.
Le contrle dintgrit (checksum) Principes

Le contrle dintgrit sapplique une srie de disques identiques. Le systme prend, par exemple, le premier bit de la premire piste de chaque disque (sauf du dernier). Il effectue sur ces donnes un OU exclusif. Le rsultat est plac dans le bit correspondant du dernier disque. Il servira reconstruire, par lopration inverse, le bit dun disque dfaillant. Cette opration est effectue pour tous les bits de toutes les pistes des disques protgs par le contrle dintgrit. Dans la figure 5.14, lopration logique pour le premier bit est : 1 OU 0 = 1 Le rsultat est plac dans le bit correspondant du troisime disque.
187
1010
0011
1010 + 0011 1001
1001
Figure 5.14 : OU logique utilis pour le contrle dintgrit.
Tout se passe comme si un disque protgeait les autres, mais en fait linformation de contrle est rpartie sur toutes les units concernes ce qui vite de surcharger un bras daccs. Chaque disque hberge donc une portion de linformation qui permettra de reconstruire la partie correspondante dun autre disque dfaillant. Il faut rajouter cela que toutes les donnes places sur les disques nont pas besoin dtre protges. Certaines nont dintrt que pour les travaux en cours, ou ne sont utilises que temporairement par le systme. Elles sont donc places dans une partie non protge des disques. Nous ne dtaillerons pas ici le calcul de cet espace. La configuration type dune srie de disques protgs par le contrle dintgrit est reprsent en figure 5.15.
188
Non protg
Non protg
Non protg
Disque 1
Disque 2
Disque 3
Figure 5.15 : structure dune srie de disques sous contrle de validation. Les parties grises reprsentent les donnes de contrle.
On constate que cette fonction consomme pratiquement un disque quel que soit le nombre dunits protges (au maximum 8). Le contrle dintgrit est mis en place partir du menu Dedicated Service Tools lors dun IPL sous contrle de loprateur.
Reprise
En cas dincident sur un disque protg par le contrle dintgrit, le systme sarrte. Il faut alors remplacer le disque dfaillant et reconstruire les donnes partir des informations situes sur les autres units. Cette opration est parfois longue et pnalisante car les applications ne peuvent tre actives.
Performances
Le contrle dintgrit est consommateur de ressources car le processeur de lAS/400 effectue beaucoup plus de travail. On estime environ 10 % lutilisation de CPU supplmentaire, ce qui est important !
Conclusions
Le contrle dintgrit tait couramment utilis au dbut de lAS/400. Il est consommateur de ressources CPU, de disques et mme de mmoire principale. Il ne permet pas un rtablissement rapide sans arrter le systme et savre inefficace dans le cas de la panne simultane de deux disques (exceptionnelle, il est vrai !).
189
Il est abandonn petit petit au profit des disques miroirs ou des units 9337 RAID 5.
Les disques miroirs (mirroring)

Il sagit dun dispositif physique qui consiste doubler la structure de stockage dun ASP. Chaque disque son image exacte sur un autre disque de mme type. Le systme crit sur ces deux units en mme temps et peut lire sur lune ou lautre selon la disponibilit des bras daccs. En cas de panne de lun des disques, le systme continue fonctionner sans interruption. Un message remonte dans QSYSOPR pour prvenir que le mirroring est dsactiv pour cette unit. Les oprations continuent avec lautre disque, qui nest plus protg. Le changement du disque dfectueux peut mme, sur certains modles, tre ralis sans arrt du systme. Le mirroring est mis en place lors dun IPL sous contrle de loprateur, par le menu Dedicated Service Tools. La protection peut tre ralise pour les disques seulement, mais elle peut aussi tre active au niveau du contrleur, de lIOP et mme du bus condition, bien videmment, de doubler ces dispositifs. Le mirroring est certainement la mthode de protection la plus fiable mais elle est relativement onreuse car elle impose lacquisition de nombreux disques. Elle reste le meilleur moyen pour scuriser les anciens disques tels que les 9332, 9335, 9336... Dans les nouvelles configurations on prfre gnralement utiliser des disques de type RAID 5 (tels que les IBM 9337) qui demandent un investissement moins important tout en procurant une excellente protection.
Les disques de type RAID 5 Principes

Avec la V2R2M0 de lOS/400 sont apparus les disques IBM 9337 disposant du mode RAID 5. Dautres constructeurs proposent aujourdhui de telles configurations qui ont tout ou partie des caractristiques de ces disques IBM. Ces nouveaux supports sont en tous points remarquables et ne cessent dvoluer en terme de capacit de stockage, de quantit de mmoire cache, de performance... Les modles 9337 RAID 5 dits haute disponibilit disposent dune protection comparable, dans le principe, ce que nous avons vu pour le contrle dintgrit (figure 5.14). Il ny a toutefois pas despace non protg. La grande diffrence
190
rside essentiellement dans le fait que ce nest plus la CPU de lAS/400 qui travaille mais le contrleur. Limpact sur les performances nest pas ngatif comme pour le contrle dintgrit, bien au contraire. Les mmoires cache en criture et en lecture procurent des temps de rponse jamais atteints jusque l.
Reprise
Lors de la dfaillance dun disque, le systme ne sarrte pas et les applications peuvent continuer fonctionner. Le contrleur reconstitue les donnes du disque manquant la demande laide des donnes des autres disques. Il continue mme simuler lcriture sur ce disque en mettant jour les informations de contrle dans la partie correspondante dun autre disque. Lutilisateur aura seulement des temps de rponse dgrads. Le remplacement de lunit dfaillante est effectu sans arrter le systme. Une fois cette opration termine, le contrleur reconstruit les donnes sur le nouveau disque ( temps perdu !) tout en continuant servir les donnes pour les applications.
Conclusions sur les disques RAID 5

Les disques RAID 5 constituent aujourdhui la meilleure adquation entre le prix, la disponibilit et la protection des donnes. Le mirroring est prfrer pour les donnes hautement sensibles, ou pour des configurations disposant encore de disques 9332, 9335, 9336 ou compatibles.
Conclusions sur la scurit et lintgrit

LAS/400 dispose de tous les atouts lui permettant davoir une scurit optimale, adapte aux besoins de chacun, tout en prservant lintgrit des donnes dans tous les cas de figure. Un systme correctement protg doit avoir un niveau de scurit (valeur systme QSECURITY) suprieur ou gal 30. La journalisation (et ventuellement le contrle de validation) doit tre appliqu sur les fichiers sensibles de lentreprise. Pour les systmes o la disponibilit doit tre quasiment permanente, il faut absolument mettre en place un dispositif tel que les disques RAID 5 ou ventuellement le mirroring. Enfin, les sauvegardes constituent la base de la reprise. Elles doivent toujours tre considres comme un des lments essentiels de la protection des donnes.
191

ADDPFCST ADDPFTRG APYJRNCHG CHGJRN CHGPFCST CHGRCYAP COMMIT CRTDUPOBJ CRTJRN CRTJRNRCV DLTF DSPFD DSPJRN DSPRCYAP EDTRBDAP EDTRCYAP ENDCMTCTL ENDJRNAP RMVJRNCHG RMVPFCST RMVPFTRG ROLLBACK SAVCHGOBJ SAVLIB SAVOBJ SNDJRNE SNDPGMMSG SNDUSRMSG STRCMTCTL STRJRNAP STRJRNPF WRKJRN WRKJRNA
ajouter une contrainte dintgrit rfrentielle un fichier physique ; ajouter un programme dclencheur un fichier physique ; appliquer les modifications contenues dans des rcepteurs de journaux ; modifier les caractristiques dun journal ; modifier une contrainte dintgrit rfrentielle ; modifier les caractristiques de SMAPP dans un programme ; valider une transaction ; dupliquer un objet ; crer un journal ; crer un rcepteur de journal ; dtruire un fichier ; afficher la partie descriptive dun fichier ; afficher le contenu des postes dun journal ; afficher les caractristiques de SMAPP ; modifier les caractristiques des chemins daccs reconstruire ; modifier les caractristiques de SMAPP en interactif ; arrter le contrle de validation ; arrter la journalisation des chemins daccs ; annuler les modifications contenues dans des rcepteurs de journaux ; enlever une contrainte dintgrit rfrentielle ; enlever un programme dclencheur ; invalider une transaction ; sauvegarder les objets modifis depuis une sauvegarde ; sauvegarder des bibliothques ; sauvegarder des objets ; envoyer un poste dans un rcepteur de journal ; envoyer un message destination dune PGMQ ; envoyer un message destination dun utilisateur ; dmarrer le contrle de validation ; dmarrer la journalisation des chemins daccs ; dmarrer la journalisation des fichiers physiques ; grer les journaux ; grer les attributs dun journal ;
192
WRKPFCST
grer les contraintes dintgrit rfrentielle.

CMDPF, FILE, FILE2, CMDFILE, CMDMBR, CMDDBF, CMDDB, CMDCMT, CMDBACK, CMDJRN, CMDJRNRCV, CMDROLL.
193
SECURITE ET INTEGRITE DES DONNEES

Introduction La journalisation Les principes La journalisation des fichiers physiques La journalisation des chemins daccs Conclusions sur la journalisation Le contrle de validation Principes Mise en uvre Lobjet de notification Les journaux Le contrle de validation deux phases Conclusions sur le contrle de validation Les contraintes dintgrit rfrentielle Introduction Mise en uvre Les cls La gestion La journalisation Exemple en RPG Conclusions Les dclencheurs (triggers) Mise en uvre Le programme dclencheur Exemple en langage de contrle Exemple en RPG Remarques Conclusions La sauvegarde et la restauration La scurit Les dispositifs matriels Le contrle dintgrit (checksum) Les disques miroirs (mirroring) Les disques de type RAID 5
125
125 127 127 140 143 147 147 147 149 152 160 161 162 162 162 164 166 168 169 169 173 173 174 175 178 179 182 183 183 184 185 186 189 189
194
Conclusions sur la scurit et lintgrit Les principales commandes Les principaux menus
190 191 192
195
9
9337 137; 181
E
141 143 ENDCMTCTL 146 ENDJRNAP 142 ENTDTA 138
EDTRBDAP EDTRCYAP
A
176 159 ADDPFTRG 168 ALTER TABLE 161 APYJRNCHG 136; 139 ASP 126
ACCPTH ADDPFCST
F
FILE
138
B
Batterie 125
I
image aprs 128 image avant 128 intgrit 125 invalidation 146 INZPFM 136 IPL 144; 181
C
C2 178 CALL 175 CHAIN 157 checksum 126; 179 chemin daccs 158 CHGPFCST 163 cl 161 Client Access/400 178 client/serveur 178 CLRPFM 136; 140 CMTID 149 COMIT 146 COMMIT 146; 170 contrainte dintgrit rfrentielle 157 contrle dintgrit 126; 179 contrle de validation 126; 145 CRTJRN 129; 135 CRTJRNRCV 129; 135
J
journal 128; 155 Journalisation 126; 127; 143
L
lASP 135 lINFDS 164 lIPL 141 LCKLVL 146
M
144 161 mirroring 181 MOVOBJ 136
MAINT MAXMBR
D
DDM 157 dclencheur 126; 167 DFU 164 disque miroir 126; 181 DLTM 139; 140 DRDA 140; 167; 178 DSPFD 163; 176 DSPJRN 133; 139
N
NFYOBJ
149
O
objet de notification 149 OMTJRNE 136; 138
126
OPNQRYF
144
P
performance 136 poste 127
Q
178 178 QAUDLVL 178 QCPFMSG 171 QSECURITY 182 QSYSOPR 181 QTEMP 144 Query 144
QAUDCTL QAUDJRN
sauvegarde 137 SAVACT 176 SAVCHGOBJ 137; 176 SAVLIB 136; 137; 176 SAVOBJ 136; 137; 176 scurit 125; 177 SNDJRNE 138 SNDPGMMSG 171 sous-fichier 149 SQL 144; 157 STRCMTCTL 146 STRJRNAP 129; 142 STRJRNPF 129; 136; 138
T
trigger 167 TYPE 138
R
RAID 181 RAID5 126 RECOVER 141 RETRN 175 RGZPFM 139; 140 RMVJRNCHG 136; 140 RMVM 136 RMVPFCST 163 RNMOBJ 136 ROLBK 146 ROLLBACK 146; 170 RPG IV 168 RPG/400 168
U
un rcepteur de journal 128 UNIQUE 159 UPDAT 164
V
validation 146
W
164 133; 139 WRKJRNA 132 WRKPFCST 163
WRITE WRKJRN
S
S.M.A.P.P. 143
Chapitre 6
SQL/400
SQL/400 est limplmentation de la norme SQL dans lOS/400. Il reprsente en fait un langage, des outils facilitant la saisie et le lancement de requtes, un prcompilateur permettant dinclure des ordres SQL dans des programmes et des commandes de gestion de lenvironnement.
Introduction
SQL (Structured Query Language) est un standard, la fois au niveau du march (il est disponible sur un nombre incalculable de produits et de plates-formes) et au niveau des organismes de normalisation (ANSI, ISO, IBM avec SAA...). Cest le langage le plus utilis pour accder aux donnes dun SGBD relationnel et, ce titre au moins, il se devait dtre support par lOS/400. Cette large implantation fait de SQL un langage idal pour travailler dans un environnement de bases de donnes rparties. Il constitue notamment larmature de DRDA et permet le dveloppement dapplications de type client/serveur. Par tous ces aspects, SQL devient incontournable sur lAS/400, comme sur beaucoup de systmes. Il permet de grer les donnes et les diffrents composants de la base de donnes. Cest un vritable environnement.
186
SQL est simple dapproche : on indique ce que lon veut et non pas comment on doit faire pour y arriver. Sa syntaxe est proche du langage naturel et sappuie sur un petit nombre de mots-cls. Son apprentissage est donc rapide. Autre avantage, ce langage est le mme pour lutilisateur final, pour le dveloppeur et pour le gestionnaire des donnes. SQL/400 correspond un logiciel sous licence (code 5738-ST1 en version 2 et 5763-ST1 en version 3 de lOS/400). Il apporte principalement : une interface interactive ; Query Manager, un produit comparable Query/400 mais gnrant du SQL ; et un prcompilateur qui permet dinclure des requtes SQL dans des langages de haut niveau (RPG, Cobol...). Il est important de prciser que ces programmes, une fois compils, pourront tre excuts sur nimporte quel systme, mme sil ne dispose pas du logiciel SQL. Il pourrait faire, lui seul, lobjet dun ouvrage complet. Je ne prsenterai ici que les bases de ce langage et les particularits de SQL/400. Pour plus de dtails, je renvoie le lecteur des ouvrages spcialiss.
Lenvironnement SQL
Sur lAS/400, on peut utiliser SQL de deux manires : sur des objets de type *FILE crs partir de DDS ; sur des structures appartenant un environnement SQL. Cette notion est importante car elle signifie que lon peut crer des fichiers partir de DDS et grer leurs donnes avec SQL. Il est courant, par exemple, dutiliser SQL en interactif pour un besoin prcis sur un fichier qui est habituellement trait avec des programmes classiques en RPG ou en Cobol. Mais SQL propose en plus un environnement complet appel collection. Une collection peut tre considre comme une base de donnes part entire. Elle contient les donnes, les vues sur ces donnes, un journal et son rcepteur, et mme des structures pour se grer elle-mme. Avant daller plus loin dans la description de ce langage, il est important de dfinir les termes que nous devons utiliser.
6 - SQL/400
187
Terminologie
Les termes employer dans lenvironnement SQL sont hrits du modle relationnel. Voici une quivalence avec les objets ou structures de lOS/400 :
Terminologie SQL Collection Table Vue Index Colonne Ligne Terminologie AS/400 Bibliothque Fichier physique Fichier logique sans cl Chemin daccs Zone Enregistrement
Une collection est implmente sous la forme dune bibliothque. Elle regroupe notamment des tables qui contiennent les donnes, les vues qui sont des manires de voir ces donnes et des index qui permettent laccs rapide partir de cls. On y trouve mme une sorte de dictionnaire sous la forme de fichiers dont le nom commence par QIDC. Pour grer une collection, SQL utilise des vues extraites de fichiers systme placs dans QSYS et dont les noms commencent par QADB. Ces vues sont ranges dans la collection elle-mme en version 2 de lOS/400 et dans la bibliothque QSYS2 en version 3. Lensemble de ces vues est appel catalogue.
Le catalogue
Voici les principales vues composant le catalogue :
SYSCOLUMNS SYSINDEXES SYSKEYS SYSPACKAGE SYSTABLES SYSVIEWS
contient la liste de toutes les colonnes utilises par les tables et les vues ; contient des informations sur tous les index ; contient la liste de toutes les colonnes composant les cls des index ; contient la liste de tous les objets de type *SQLPKG ; contient la liste de toutes les tables et de toutes les vues ; contient des informations sur toutes les vues.
Il est ais dutiliser ces vues (avec SQL !) pour extraire des informations sur une collection.
Conventions SQL
188
Dans les commandes de lOS/400, le nom de la bibliothque et le nom de lobjet qualifi sont spars par le caractre /. La norme SQL prconise de sparer le nom de la collection du nom de lobjet (table, vue...) par le point (.). Lune ou lautre de ces conventions peuvent tre utilise sur lAS/400 condition de le prciser lenvironnement dans le paramtre NAMING (par les commandes STRSQL, CRTSQLCOL, RUNSQLSTM...). Dans les exemples suivants nous utiliserons la convention SQL, cest--dire que la table TAB1 de la collection COL1 sera qualifie par :
COL1.TAB1
Le caractre / nest pas reconnu par les autres systmes comme sparateur. Il ne pourra tre utilis que dans le cas o la base de donnes (locale ou distante) est situe sur un AS/400.
Utiliser une collection ou non ?

Nous avons dj signal que SQL peut grer des donnes places dans des fichiers situs en dehors dune collection. Alors pourquoi utiliser une collection ? Voici quelques lments de rponse : une collection est un environnement complet, homogne, contenant mme un journal. Cest une base de donnes part entire ; les tables places dans une collection sont automatiquement journalises et le contrle de validation peut tre simplement mis en place par le paramtre COMMIT des commandes lanant SQL (STRSQL, RUNSQLSTM...) ; le contrle de validation est obligatoire si on dsire accder une base de donnes AS/400 partir dune autre plate-forme. Dans ce cas, lutilisation dune collection simplifie le travail de mise en place de lenvironnement ; le catalogue permet de grer les diffrentes structures de la collection. Mais la mise en uvre dune collection a ses dtracteurs. La cration dune collection est une opration lourde pour le systme et la journalisation associe au contrle de validation ne favorise pas les performances. Dune manire gnrale, on peut dire que si lon dsire travailler dans un environnement purement SQL, comme on peut le faire sur dautres plates-formes, il est prfrable de se placer dans le cadre dune collection. Sinon, on peut se
6 - SQL/400
189
contenter de ranger les fichiers dans des bibliothques classiques. Il est alors prudent de les journaliser.
190
Les lments du langage SQL

Dans cette partie, nous allons voir les lments de base du langage SQL qui nous permettront de mieux cerner ses caractristiques et dexcuter nos premires transactions. Mais avant tout, nous allons rapidement dcrire les environnements avec lesquels nous allons saisir et lancer ces requtes.
Les environnements dexcution

Pour une meilleure comprhension de ce chapitre et surtout de SQL, il est intressant de disposer dun terminal reli un AS/400 possdant ce produit.
SQL interactif
Le plus simple pour tester SQL est de lancer lenvironnement interactif par la commande STRSQL. On se retrouve alors devant un cran qui nous permet de saisir nos requtes, puis de les excuter grce la touche ENTREE. Leur excution a lieu tout de suite et le rsultat ventuel est renvoy lcran. Ce mode est idal pour apprendre SQL, mais les responsables dexploitation sont parfois rticents le mettre la disposition des utilisateurs car il peut provoquer des dgradations notables de performances sil est mal utilis. On peut, en effet, lancer des requtes qui vont analyser des fichiers de plusieurs millions denregistrements, parfois sans le savoir, ou sans en avoir rellement besoin, juste pour tester. Une invite est disponible par lintermdiaire de la touche F4. Elle nous permet dignorer une grande partie de la syntaxe.
Query Manager
Query Manager est un outil livr avec SQL qui permet de saisir des requtes, de mettre en forme les rapports gnrs, de grer les tables et mme de limiter les actions de certains utilisateurs. Cest un vritable environnement lanc par la commande STRQM. Pour la saisie de requtes, il dispose de deux interfaces : la premire, nomme SQL, prsente un diteur de type SEU qui nous laisse entrer les instructions. Une aide la saisie, du mme type que linvite du mode interactif, est disponible avec la touche F4 ;
6 - SQL/400
191
la seconde, nomme PROMPT, est comparable Query/400. Elle nous permet dignorer le langage SQL. Une analyse ainsi cre peut tre transforme en requte SQL. Le choix entre ces deux interfaces est effectu en utilisant la touche F19 au niveau du menu gnral de gestion des requtes. Le mode SQL autorise la saisie de variables. Leur nom est prcd du caractre & comme en langage de contrle. Au moment de lexcution, le systme demande lutilisateur de saisir la valeur de cette variable via la file dattente de messages externe. Les requtes peuvent tre enregistres, puis rappeles et modifies. La commande STRQMQRY lance leur excution. Query Manager permet de grer le format des rapports ce qui est impossible avec SQL interactif. On peut ainsi dfinir le titre et le formatage des colonnes, len-tte et le pied de page... Enfin, ce produit permet de dfinir des caractristiques pour chaque utilisateur (options par dfaut, ordres SQL autoriss et interdits...) dans lenvironnement Query Manager.
La commande RUNSQLSTM
Avec la V2R3M0 de lOS/400 est apparue une commande qui permet de lancer une requte SQL en batch. Son utilisation est trs simple : saisie de la requte dans un membre source (de type TXT, par exemple, car il ny a pas de vrification de la syntaxe par lditeur) ; soumission de cette requte par la commande RUNSQLSTM dans un SBMJOB. Pour lancer en batch la requte contenue dans le membre source REQ1 du fichier BD400, la commande est :
SBMJOB CMD(RUNSQLSTM SRCFILE(*LIBL/BD400) SRCMBR(REQ1))
Lors de lexcution du travail batch, les ordres SQL sont interprts, il ny a aucune compilation.
Conclusions
192
Nous avons rapidement dcrit les diffrentes possibilits quun utilisateur a sa disposition pour lancer des requtes SQL. Le programmeur pourra inclure des ordres SQL dans des programmes RPG, Cobol ou autres, mais nous verrons cela plus tard, lorsque nous aurons dfini plus prcisment les caractristiques de ce langage.
Les conventions
Les conventions suivantes ont t choisies pour illustrer les exemples : le point spare le nom dune collection (ou dune bibliothque) du nom dune table ou dune vue. SQL doit donc tre dmarr avec le paramtre NAMING(*SQL). Mais, dune manire gnrale, le nom des objets nest pas qualifi dans nos exemples ; cest alors la base de donnes par dfaut qui est choisie. Celle-ci peut tre dfinie au niveau du paramtre DFTRDBCOL des commandes de cration de programme (CRTSQLRPG...) ou tre tout simplement cite dans la liste de bibliothque ; la prsentation des requtes sur plusieurs lignes ne rpond aucune contrainte syntaxique, elle a seulement pour ambition de faciliter la lecture ; pour une meilleure lisibilit, les ordres SQL sont en caractres majuscules et les donnes spcifiques lexemple sont en minuscules, mais les deux types de caractres peuvent tre utiliss indiffremment ; seuls les principaux ordres sont dcrits.
La dfinition des structures SQL CREATE COLLECTION

Cet ordre permet de crer une collection. Sur lAS/400, il dfinit une bibliothque et place dedans de nombreux objets, notamment : le journal QSQJRN et son rcepteur QSQJRN0001; le catalogue, c'est--dire des tables et des vues ; un dictionnaire, objet de type *DTADCT, qui a le mme nom que la collection. La cration dune collection est une tche relativement lourde pour le systme, effectuer, si possible, en dehors des priodes de forte activit.
6 - SQL/400
193
Exemple
CRTCOL db400
cre la collection DB400.
194
CREATE TABLE
Cet ordre permet de crer une table (au sens SQL) ou un fichier physique pour lOS/400, dans une collection ou plus gnralement dans une bibliothque. Pour une collection, la table est rfrence dans le catalogue et se trouve automatiquement journalise. A la suite de cet ordre on doit indiquer le nom (qualifi) de la table et dcrire les zones qui la composent. Les types Voici les principaux types qui peuvent tre dfinis pour les colonnes et leur quivalence sur lAS/400 :
Type SQL
CHAR DECIMAL DATE TIME TIMESTAMP VARCHAR SMALLINT INTEGER OU INT FLOAT
Type sur lAS/400 Alphanumrique ; Dcimal condens ; Date ; Time ; Timestamp ; Zone de longueur variable. ALLOCATE permet de dfinir la longueur de la partie fixe ; Binaire dfini sur 2 octets ; Binaire de longueur 4 ; Nombre en virgule flottante.
Valeur indfinie Par dfaut avec SQL, une zone peut prendre la valeur indfinie (NULL). Pour inhiber cette possibilit qui nest pas standard sur lAS/400, et qui nest pas bien supporte par des langages comme le RPG/400, il faut prciser NOT NULL en regard de chaque zone dcrite. WITH DEFAULT initialise ces zones avec la valeur par dfaut (0 pour du numrique, des blancs pour de lalphanumrique). Exemple
CREATE TABLE db400.tab1 (zone1 CHAR(5) NOT NULL, zone2 DECIMAL(8,2) NOT NULL , zone3 DATE NOT NULL, zone4 INT)
cre la table TAB1 dans la collection DB400. Elle contient ZONE1 de type Alphanumrique de longueur 5, ZONE2 de type Dcimal condens pouvant avoir
6 - SQL/400
195
8 positions dont 2 derrires la virgule (123456.78), ZONE3 de type Date et ZONE4 de type Binaire de longueur 4 qui peut avoir la valeur indfinie. Contrainte dintgrit rfrentielle Lors de la cration dune table, on peut lui associer une contrainte dintgrit rfrentielle, une cl primaire ou une cl unique comme avec la commande ADDPFCST. La CIR peut tre ajoute une table dpendante lors de sa cration par lordre CREATE TABLE ou ensuite avec ALTER TABLE. Lexemple suivant dfinit la table TAB1, dpendante de TAB2. La contrainte sappuie sur la colonne ZONE1 des 2 tables et porte le nom CTR1 :
CREATE TABLE db400.tab1 (zone1 CHAR(5) NOT NULL, zone2 DECIMAL(8,2) NOT NULL , CONSTRAINT ctr1 FOREIGN KEY (zone1) REFERENCES tab2 (zone1) ON DELETE NO ACTION ON UPDATE RESTRICT)
CREATE VIEW
Cet ordre permet de crer une vue. Rappelons quune vue peut tre assimile un fichier logique sans cl. Cest une manire de voir les enregistrements dune ou de plusieurs tables ou vues. Le tri est dfini lors de la slection des enregistrements. Il est donc tabli dynamiquement en sappuyant ventuellement sur un index existant. Une requte SQL est associe au CREATE VIEW. Elle dfinit les tables, les vues, les enregistrements et les colonnes qui seront accessibles au travers de cette structure. Exemple
CREATE VIEW vue1 AS SELECT zone4, zone1, zone2 FROM tab1 WHERE zone2 > 0
cre la vue VUE1 qui sappuie sur TAB1 et voit les zones ZONE4, ZONE1 et ZONE2 pour les enregistrements dont le contenu de ZONE2 est suprieur 0.
CREATE INDEX
196
Cet ordre cre un index. Un index est un chemin daccs qui sappuie obligatoirement sur un fichier physique. Il est utilis par loptimiseur sil le juge utile, notamment pour vrifier lunicit des cls et lorsquun tri est demand dans une requte (avec les ordres ORDER BY et GROUP BY). Exemples
CREATE INDEX ind1 ON tab1 (zone2)
cre lindex nomm IND1 sappuyant sur ZONE2 de la table TAB1 ;

CREATE UNIQUE INDEX ind2 ON tab1 (zone1, zone3)
cre lindex IND2 partir de la cl compose de ZONE1 et de ZONE3. Deux enregistrements de la table TAB1 ne pourront avoir mme valeur de cl ;
CREATE INDEX ind3 ON tab1 (zone1 ASC, zone3 DESC)
cre lindex IND3 laide duquel les enregistrements apparatront tris de faon ascendante sur ZONE1 et descendante sur ZONE3.
CREATE SCHEMA
Cet ordre permet de dfinir tout un environnement en une seule opration car il autorise la cration dune collection, de tables, de vues et dindex et permet mme de dfinir des droits sur ces objets. Il est apparu en V2R3M0 de lOS/400 et doit tre codifi dans un membre source, puis lanc avec la commande RUNSQLSTM, donc en batch. Exemple
CREATE SCHEMA col1 CREATE TABLE tab1 (zone1 CHAR(5) NOT NULL, zone2 DECIMAL(8,2) NOT NULL) CREATE INDEX ind1 ON tab1 (zone2) GRANT ALL ON tab1 TO pgmr1
6 - SQL/400
197
cre la collection COL1, la table TAB1 et lindex IND1. Tous les droits (au sens SQL) sont donns lutilisateur PGMR1.
198
DROP
Cet ordre dtruit une structure SQL. DROP COLLECTION efface une collection et tout ce qui est dedans. DROP TABLE dtruit une table et tout ce qui sy rapporte (vues, index, autorisations). Exemple DROP TABLE DB400.tab1 dtruit la table TAB1 ainsi que les vues et les index qui lui sont associs.
ALTER TABLE
Habituellement, cet ordre est utilis pour modifier la structure dune table, mais cela est impossible sur lAS/400 ( ce jour, car cette fonction est prvue pour la prochaine version du systme). Il est apparu avec la V3R1M0 de lOS/400 pour une autre utilisation. Il sert associer une contrainte dintgrit rfrentielle une table qui existe dj. Pour une nouvelle table, la contrainte peut tre dfinie dans le CREATE TABLE. En dehors de lenvironnement SQL, on peut utiliser la commande ADDPFCST qui a les mmes fonctionnalits. Exemple
ALTER TABLE tabdep ADD CONSTRAINT nomcont FOREIGN KEY (zone1, zone2) REFERENCES nompar (z1, z2) ON DELETE NO ACTION ON UPDATE RESTRICT
ajoute une contrainte nomme NOMCONT entre le fichier dpendant TABDEP et le fichier parent NOMPAR (se reporter la description des CIR du chapitre 5 pour avoir plus dinformation sur ces diffrentes valeurs).
La gestion des donnes SELECT

Cet ordre est probablement le plus utilis, car il permet dextraire des enregistrements de la base de donnes, choisis selon certains critres, puis tris sur
6 - SQL/400
199
une ou plusieurs colonnes. Il est extrmement puissant mais sa syntaxe est simple : cest une des forces de SQL.
200
Slection simple La slection de base consiste citer les colonnes extraire au niveau de la clause SELECT et nommer la table ou la vue concerne laide de FROM. Par exemple :
SELECT zone1, zone2 FROM tab1
renvoie le contenu de ZONE1 et de ZONE2 pour tous les enregistrements de TAB1. Une colonne peut aussi tre le rsultat dun calcul :
SELECT zone1, salaire / 12 mensuel FROM tab1
renvoie dans la deuxime colonne le contenu de SALAIRE divis par 12. Celle-ci est renomme MENSUEL ( partir de la V3R1M0 de lOS/400). Le caractre * permet de slectionner toutes les colonnes. Par exemple,
SELECT * FROM SYSTABLES
renvoie le contenu de toutes les zones pour tous les enregistrements de SYSTABLES. Cette table est un des lments du catalogue qui contient des informations sur toutes les tables dune collection (ou de toutes les collections partir de la V3R1M0 de lOS/400 ; elle est alors place dans QSYS2). La clause DISTINCT supprime les lignes en double. Elle doit tre cite immdiatement aprs SELECT.
SELECT DISTINCT zone1, zone2 FROM tab1
Critres de slection La clause WHERE permet de faire une slection des enregistrements extraire. Sa syntaxe est aussi trs simple :
SELECT * FROM tab1 WHERE zone2 > 10
ramne toutes les colonnes pour les enregistrements qui ont ZONE2 suprieur 10. La proposition logique associe au WHERE peut tre relativement complexe car elle autorise :
6 - SQL/400
201
les oprateurs AND et OR :

SELECT * FROM tab1 WHERE (zone2 > 10 OR zone1 < 5) AND (zone3 = 15 OR zone4 =A)
le prdicat BETWEEN pour dfinir un domaine de valeurs, bornes comprises :

SELECT * FROM tab1 WHERE zone2 BETWEEN 10 AND 50
le prdicat LIKE pour rechercher une chane dans une colonne de type Alphanumrique. Le caractre % remplace un nombre quelconque de caractres, _ en substitue un seul. Par exemple :
SELECT * FROM tab1 WHERE zone3 LIKE %AB% AND zone4 LIKE _X%
slectionne les enregistrements qui ont ZONE3 contenant la chane AB nimporte quelle position et ZONE4 ayant un X en deuxime position ; de dfinir une liste de valeurs avec le prdicat IN :
SELECT * FROM tab1 WHERE zone3 IN (5, 15, 25)
le test des valeurs indfinies par IS NULL ou IS NOT NULL :

SELECT * FROM tab1 WHERE zone5 IS NOT NULL
Tri Les enregistrements peuvent apparatre tris selon les colonnes dfinies grce la clause ORDER BY :
SELECT * FROM tab1 WHERE zone2 > 10 ORDER BY zone1
Les colonnes sur lesquelles seffectue le tri doivent tre cites dans le SELECT. Leur nom peut tre remplac par leur position dans la liste, par exemple :
SELECT zone1, zone2, zone3 FROM tab1 WHERE zone2 > 10 ORDER BY 1
202
provoque le tri sur la colonne ZONE1, cite en premier dans le SELECT. Fonctions scalaires Les fonctions scalaires permettent deffectuer des oprations pour chaque ligne renvoye. Elles contiennent essentiellement : des fonctions mathmatiques (sinus, cosinus, racine carre, logarithme...) ; des fonctions de conversion de types ; des fonctions de traitement des chanes de caractres ; des fonctions de traitement de date. Par exemple :
SELECT COS(zone1), SQRT(zone2) FROM tab1
renvoie, pour chaque ligne, le cosinus de ZONE1 et la racine carre de ZONE2. Fonctions de colonnes Ces fonctions permettent deffectuer un calcul sur lensemble des valeurs dune colonne. On peut ainsi calculer pour une colonne la moyenne (AVG), la somme (SUM), lcart type (STDDEV), la variance (VAR), la plus grande (MAX) et la plus petite (MIN) de toutes les valeurs renvoyes. Le nombre denregistrements rpondant aux critres de slection est donn par COUNT(*). Toutes les colonnes cites dans le SELECT doivent tre de ce type car un seul enregistrement est retourn (nous verrons une exception avec lordre GROUP BY). Par exemple :
SELECT SUM(zone1), MAX(zone2), COUNT(*) FROM tab1 WHERE zone1 > 0
renvoie une seule ligne contenant la somme de toutes les valeurs de ZONE1, la plus grande valeur contenue dans ZONE2 et le nombre denregistrements satisfaisant cette requte. Totalisations Les fonctions de colonnes que nous venons de voir renvoient un seul enregistrement. Il est parfois intressant davoir des rcapitulations intermdiaires, par groupes denregistrements ayant les mmes valeurs pour certaines zones. Par exemple, on veut extraire le montant des factures non rgles, par client. On doit
6 - SQL/400
203
obtenir autant denregistrements que de clients qui rpondent aux critres de slection. La clause GROUP BY permet de dfinir les zones qui servent tablir les groupes sur lesquels sont effectus les calculs. Au niveau du SELECT, ne peuvent figurer que les zones associes au GROUP BY et des fonctions colonnes. Par exemple :
SELECT nocli, SUM(totalfact), COUNT(*) FROM facture GROUP BY nocli ORDER BY nocli
renvoie, pour chaque client une ligne contenant son numro, le total des factures dues et le nombre de factures impayes, le tout tri par numro de client. La clause HAVING permet de donner des critres de slection sur les groupes. On peut ainsi prciser dans la requte ci-dessus que seuls les client ayant plus de deux factures impayes doivent apparatre. La clause WHERE dfinit les enregistrements qui sont retenus dans la base de donnes, alors que HAVING sert dfinir les caractristiques des groupes, composs eux-mmes partir des enregistrements prcdemment retenus. Par exemple :
SELECT tbname, COUNT(*) FROM test.syscolumns GROUP BY tbname HAVING COUNT(*) > 10
renvoie le nom des tables et des vues contenues dans la collection TEST ayant plus de 10 colonnes. SYSCOLUMNS est une vue du catalogue contenant la liste de toutes les zones dune collection. GROUP BY TBNAME provoque un regroupement par tables et vues. HAVING COUNT(*) ne retient que celles qui ont plus de 10 colonnes. Jointure La liaison entre plusieurs tables est effectue par une jointure et correspond ce que nous avons dj dfini pour les fichiers logiques joints. Les diffrentes tables doivent tre cites dans la clause FROM. Au niveau du SELECT, les colonnes dont le nom est ambigu, car prsent dans plusieurs tables, doivent tre prfixes par le nom de la table pour indiquer leur origine. Pour viter les lourdeurs de codification, les tables peuvent tre renommes dans la clause FROM. On leur donne gnralement un nom plus court, sur un ou deux caractres. La clause WHERE est importante car elle dfinit les zones et les conditions de la jointure. Si elle nexiste pas, toutes les lignes de la premire table sont mises en relation avec chacune des lignes de la seconde. Si chaque table contient cent
204
enregistrements, le rsultat donnera alors 10 000 lignes. Il faut procder prudemment dans ce domaine sous peine de provoquer leffondrement du systme. Pour extraire dans une mme requte des donnes sur une facture et des indications sur le client, on peut imaginer lexemple suivant :
SELECT c.nocli, nomcli, adresse, nofact, f.total FROM client c, facture f WHERE f.nocli = c.nocli
o la table CLIENT est renomme C et FACTURE, F. La jointure est effectue sur la zone NOCLI des deux tables. Slections imbriques Dans la clause WHERE, un des lments constituant les critres de slection peut tre le rsultat dune requte. On obtient donc des SELECT imbriqus. La sous-requte peut renvoyer une seule valeur ou une liste de valeurs. Les oprateurs ne sont pas les mmes dans ces deux cas : pour une valeur unique les oprateurs sont de type comparaison (=, >, <...) ; pour une liste de valeurs les oprateurs sont de type ensembliste (IN, ALL, ANY, SOME). La sous-requte ne doit concerner quune colonne. Lexemple suivant prsente une requte qui extrait les employs qui ont le plus haut salaire de la socit :
SELECT noemp, salaire FROM employe WHERE salaire = (SELECT MAX(salaire) FROM employe)
le SELECT imbriqu est excut le premier. Il ramne la valeur du plus haut salaire. Il suffit alors dextraire le nom des employs ayant ce salaire. Des SELECT imbriqus peuvent aussi tre utiliss dans la clause HAVING. Lexemple suivant permet dextraire les clients dont la moyenne des factures est suprieure la moyenne des factures de tous les clients :
SELECT nocli, AVG(montant) FROM facture GROUP BY nocli
6 - SQL/400
205
HAVING AVG(montant) > (SELECT AVG(montant) FROM facture) ORDER BY nocli
Des requtes plus complexes les unes que les autres permettent de rsoudre quantit de cas dcole et sont les cauchemars des lves en informatique. Nous ne rentrerons pas dans ce cycle infernal...
INSERT INTO
Cet ordre ajoute des enregistrements dans une table ou dans une vue. Lutilisation la plus simple consiste insrer un enregistrement en prcisant les valeurs de chaque colonne. Par exemple :
INSERT INTO tab1 VALUES (50, CYCLOMOTEUR)
ajoute un enregistrement ayant la valeur numrique 50 dans la premire zone et la chane CYCLOMOTEUR dans la seconde. Pour les cas plus complexes o toutes les colonnes ne sont pas traites, il est possible de citer les colonnes de la table qui recevront les donnes. Leur ordre doit correspondre lordre des donnes :
INSERT INTO tab1 (code, nom) VALUES (50, CYCLOMOTEUR)
la zone CODE recevra la valeur 50 et la zone NOM la chane CYCLOMOTEUR. Une table pouvant tre alimente partir dune requte, SELECT remplace donc VALUES. Il faut sassurer que les colonnes sont dans le bon ordre ou, ventuellement, dfinir leur position. Par exemple :
INSERT INTO tab1 (code, nom) SELECT codeart, nomart FROM article WHERE codeart > 100
copie dans TAB1 le code et le nom des articles qui ont CODEART suprieur 100. Il existe, enfin, une autre possibilit dinsrer plusieurs enregistrements en une seule opration mais cela est du ressort de la programmation et sera donc vu plus loin.
206
UPDATE
Cet ordre permet de modifier une srie denregistrements. La clause WHERE dfinit les enregistrements mettre jour, SET donne la nouvelle valeur et
6 - SQL/400
207
UPDATE
prcise le nom de la table ou de la vue :

UPDATE tab1 SET zone2 = 50 WHERE zone1 = 500
les enregistrements dont ZONE1 est gal 500 se verront attribuer la valeur 50 pour ZONE2. La proposition associe la clause WHERE est importante car elle identifie les enregistrements modifier. Une erreur est vite commise ! Lexemple suivant permet de modifier plusieurs colonnes en une seule opration (ZONE3 est augmente de 5 %) :
UPDATE tab1 SET zone2 = 50, zone3 = zone3 * 1.05 WHERE zone1 = 500
DELETE
Cet ordre permet de supprimer une srie denregistrements. Sa syntaxe est simple :
DELETE FROM tab1 WHERE zone1 = 500
provoque la destruction de tous les enregistrements qui ont ZONE1 gal 500.
Les registres spciaux

Les registres spciaux nous donnent des informations sur lenvironnement. Ils sont utiliser comme des variables, cest--dire quils sont substitus par leur contenu lors de lexcution de la requte. Voici les principaux registres :
Registre
CURRENT DATE CURRENT TIME CURRENT TIMESTAMP CURRENT SERVER USER
Contenu Date courante, type Date ; Heure courante, type Time ; Horodatage courant, type Horodatage ; Nom de la base de donnes. Cest une zone de longueur variable dun maximum de 18 ; Nom du profil utilisateur. Cest une zone de longueur variable dun maximum de 18.
208
6 - SQL/400
209
La requte suivante place dans un nouvel enregistrement de la table TAB1 le numro de la commande et la date courante :
INSERT INTO tab1 (numcom, date) VALUES (154, CURRENT DATE)
Le contrle de validation
Nous avons dj signal que la journalisation des tables dans une collection est automatique. Le contrle de validation est donc simple mettre en uvre. Il est initialis grce au paramtre COMMIT lors du lancement de lenvironnement SQL (STRSQL, RUNSQLSTM) ou lors de la cration dun programme (CRTSQLxx), il ny a donc pas prparer lenvironnement par la commande STRCMTCTL comme en programmation classique. Par dfaut, SQL interactif est lanc avec COMMIT(*NONE), cest--dire sans contrle de validation. Les programmes incluant des requtes SQL sont compils avec loption COMMIT(*CHG). Si aucun ordre COMMIT ne figure dans ces programmes, toutes les oprations modifiant les donnes seront automatiquement invalides la fin de leur excution, mme si ces programmes se terminent normalement. Il faut donc soit dsactiver cette fonction avec COMMIT(*NONE), soit utiliser lordre COMMIT. Les ordres COMMIT et ROLLBACK permettent de valider ou dinvalider une transaction. Aucun objet de notification ne peut tre utilis.
La scurit
SQL met notre disposition des ordres pour grer la scurit. Sur lAS/400, cette puissante fonction est totalement intgre au systme, si bien que les fonctions SQL ne sont quun habillage des commandes GRTOBJAUT et RVKOBJAUT. Ils sont par contre indispensables pour assurer une compatibilit avec les bases de donnes dautres plates-formes.
GRANT donne des droits un utilisateur sur une table ou sur une vue. Une partie seulement des possibilits offertes par lOS/400 est disponible au travers de motscls tels que ALL, DELETE, INSERT, SELECT... Les modifications effectues par cet ordre peuvent tre visualises par les commandes EDTOBJAUT et DSPOBJAUT. Voici trois exemples : GRANT SELECT, INSERT ON tab1 TO pgmr1, pgmr2
210
donne le droit dexcuter des requtes SELECT et INSERT sur la table TAB1 aux utilisateurs PGMR1 et PGMR2 ;
GRANT UPDATE ON tab1 TO PUBLIC
donne le droit de mise jour des enregistrements de TAB1 tous les utilisateurs nayant pas fait lobjet dautorisations particulires (comparable *PUBLIC de lOS/400) ;
GRANT ALL ON tab1 TO pgmr1
donne tous les droits (au sens SQL) sur la TAB1 lutilisateur PGMR1. Ces droits sont plus restrictifs que ceux attribus par la valeur *ALL de lOS/400. REVOKE permet de retirer des droits. Sa syntaxe est la mme que pour GRANT :
REVOKE UPDATE ON tab1 TO pgmr1
enlve le droit de mise jour des donnes de TAB1 pour lutilisateur PGMR1. Il faut rappeler que Query Manager propose de grer, pour chaque utilisateur, les ordres SQL qui lui sont autoriss ou interdits.
La connexion une base de donnes loigne

Au sein de DRDA, SQL permet simplement de se connecter une base de donnes distante. Son nom doit tre dfini au niveau du rpertoire de bases de donnes. Associes ce nom, figurent des informations sur le systme distant qui permettront lOS/400 dtablir la communication. La commande WRKRDBDIRE et ses commandes associes (ADDRDBDIRE, CHGRDBDIRE...) permettent de grer le rpertoire de base de donnes. La connexion est demande avec lordre CONNECT TO. Un profil utilisateur et un mot de passe peuvent tre spcifis. Par exemple :
CONNECT TO aslyon USER pgmr1 USING ABCDEF
provoque la connexion la base de donnes ASLYON sous le profil PGMR1 avec le mot de passe ABCDEF.
6 - SQL/400
211
En cas dchec (la communication est impossible, la base de donnes nest pas dans le rpertoire...), lapplication reste connecte lancienne base.
212
Dans le cas o le contrle de validation est actif, lordre CONNECT ne peut tre mis qu une frontire de transaction, cest--dire : au dbut de lapplication ; aprs un COMMIT ; aprs un ROLLBACK. Rappelons que le contrle de validation est obligatoire pour se connecter DB2/400 partir dun autre systme.
CONNECT RESET libre les communications avec le systme distant et connecte lapplication avec la base de donnes locale.
SQL dans les programmes

Une des forces du langage SQL est de pouvoir tre incorpor dans des programmes crits en langage de haut niveau. On possde ainsi la puissance de ces langages pour la gestion des crans, des donnes, des impressions... et les avantages de SQL pour laccs aux donnes. Cette solution est incontournable pour crire des applications portables sur des systmes hbergeant des SGBD relationnels. Tous les langages de haut niveau de lAS/400 peuvent contenir des requtes SQL (RPG/400, RPG IV, Cobol, C ILE, PL1 ... et mme Rexx). Seul le langage de contrle, qui nest pas fait pour modifier les donnes, ne le supporte pas. Nous verrons des exemples en RPG (400 et IV) qui est le compilateur le plus couramment utilis sur lAS/400, mais les principes sont les mmes pour les autres langages. Il faut noter que le mode dinclusion des requtes SQL dans un langage est pratiquement le mme pour la plupart des SGBD relationnels (Oracle, Ingres...). Le produit SQL/400 est indispensable pour dvelopper des programmes contenant des requtes SQL, mais il nest pas utilis lors de lexcution de ces programmes. On peut donc dvelopper de telles applications mme si le systme qui doit les hberger ne possde pas SQL/400. Lorsque la requte est totalement dfinie dans le source, elle est dite statique. Le prcompilateur peut efficacement loptimiser. Il est aussi possible de constituer la
6 - SQL/400
213
requte au dernier moment, lors de lexcution, en fonction de lenvironnement ou des besoins de lutilisateur : elle est alors dite dynamique. Dans un premier temps nous ne considrerons que celles qui sont statiques.
Principes
Les sources de programmes contenant des requtes SQL sont de type SQLXXX o XXX identifie le langage dans lequel il sont codifis : SQLRPG pour le RPG/400, SQLRPGLE pour le RPG IV, SQLCBL pour le Cobol... La cration de lobjet *PGM seffectue en deux tapes : tout dabord, la prcompilation transforme dans le source les requtes SQL en instructions qui sont compatibles avec le langage de programmation ; la compilation proprement dite (ou la gnration du module en environnement ILE) peut alors avoir lieu. Les ordres EXEC SQL et END-EXEC doivent encadrer les requtes. Ils servent uniquement au prcompilateur qui dtermine ainsi ses domaines dintervention. Les instructions en dehors de ces limites ne seront pas affectes. On ne peut placer quune seule requte SQL entre ces bornes. Le prcompilateur gnre un source (plac dans le fichier QSQLTEMP de QTEMP) qui est repris par le compilateur (figure 6.1). Pour visualiser son contenu, il faut compiler en interactif car la bibliothque QTEMP du travail batch nest pas accessible.
... EXEC SQL SELECT ... END-EXEC ... DS ... CALL QSQROUTE ...
Prcompilation
Compilation
Source
Source temporaire
*PGM
Figure 6.1 : la compilation dun programme contenant des requtes SQL.
Lexemple 6.1 prsente un source RPG/400 contenant une requte SQL et le source temporaire gnr par le prcompilateur.
214
Le fichier spoule gnr lorsque le prcompilateur rencontre une erreur grave est nomm QSYSPRT.
6 - SQL/400
215
Source RPG/400
FECRFAC CF E C C/EXEC SQL C+ DELETE FROM TAB1 C+ WHERE NOCLI = 50 C/END-EXEC C C WORKSTN EXFMTFMT1
EXFMTFMT2 RETRN
Source gnr par le prcompilateur

FECRFAC CF E WORKSTN ISQLCA DS I* SQL communications area I 1 8 SQLAID I B 9 120SQLABC I B 13 160SQLCOD I B 17 180SQLERL I 19 88 SQLERM I 89 96 SQLERP I 97 120 SQLERR I B 97 1000SQLER1 I B 101 1040SQLER2 I B 105 1080SQLER3 I B 109 1120SQLER4 I B 113 1160SQLER5 I B 117 1200SQLER6 I 121 131 SQLWRN I 121 121 SQLWN0 I... I 131 131 SQLWNA I 132 136 SQLSTT I* End of SQLCA C EXFMTFMT1 C*EXEC SQL C* DELETE FROM TAB1 C* WHERE NOCLI = 50 C*END-EXEC C Z-ADD00001 SQLER6 C CALL 'QSQROUTE' C PARM SQLCA C EXFMTFMT2 C RETRN Exemple 6.1 : source RPG/400 et source gnr par le prcompilateur. Remarquez que les instructions SQL sont mises en commentaires. Une partie de la data-structure SQLCA a t enleve.
216
En RPG, les requtes SQL doivent tre codifies en spcification C. EXEC SQL et END-EXEC doivent tre prcds du caractre /. Les instructions composant la requte doivent commencer par le caractre + suivi dune espace. Rappelons que par dfaut un programme contenant des requtes SQL est compil en demandant le contrle de validation. Tout programme qui ne se termine pas par un COMMIT voit ses oprations automatiquement invalides. Cette fonction peut tre dsactive en compilant le programme avec le paramtre COMMIT(*NONE).
Les variables locales

Il est fondamental de pouvoir travailler avec les variables du programme ce qui permet notamment de paramtrer les requtes. A lintrieur dun couple form par EXEC SQL et END-EXEC, le nom des variables du programme est prfix par le caractre :. Ainsi, lexemple suivant en RPG permet de dtruire lenregistrement dont le numro est contenu dans la variable NUMART :
C*Saisie du numro de larticle dtruire dans NUMART C EXFMTFMT1 C/EXEC SQL C+ DELETE FROM TAB1 C+ WHERE numart = :numart C/END-EXEC C*numart est le nom de la colonne de la table, C* :numart celui de la variable du programme
Les oprations simples

SELECT INTO Lordre SELECT INTO permet de placer le rsultat dune slection dans les variables du programme. Il faut sassurer quun seul enregistrement est renvoy, sinon lopration est plus complexe (voir le chapitre suivant). Par exemple :
C/EXEC SQL C+ SELECT zone1, zone2, zone3 C+ INTO :var1, :var2, :var3 C+ FROM tab1 C+ WHERE zone4 = :var4 C/END-EXEC
place dans la variable VAR1 le contenu de la colonne ZONE1, dans VAR2 celui de ZONE2...
6 - SQL/400
217
Lexemple 6.2 prsente un programme qui demande un numro darticle, qui affiche ses caractristiques et qui permet de les modifier. Source RPG/400
FECRART CF E WORKSTN C EXFMTSAISIE C 03 MOVE *ON *INLR C* C*RECHERCHE DE L'ENREGISTREMENT C/EXEC SQL C+ SELECT NOMART, QUANT INTO :NOMART, :QUANT C+ FROM ART1 C+ WHERE NOART= :NOART C/END-EXEC C* C*VERIFICATION DES ERREURS DE SAISIE C SQLCOD IFEQ 0 C EXFMTMODIF C *IN25 IFEQ '1' C*SI UNE MODIFICATION A ETE EFFECTUEE C* C/EXEC SQL C+ UPDATE ART1 C+ SET NOMART = :NOMART, QUANT = :QUANT C+ WHERE NOART= :NOART C/END-EXEC C* C*VALIDATION DE LA TRANSACTION C* C/EXEC SQL C+ COMMIT C/END-EXEC C ENDIF C ENDIF C 03 MOVE *ON *INLR
DDS du fichier daffichage ECRART

DSPSIZ(24 80 *DS3) CA03(03 'Sortie') R SAISIE 1 28'Modification d''un article' COLOR(WHT) 4 5'Numro de l''article modifier:' 4 37 OVERLAY CHANGE(25 'Modification') 8 6'Libell:' 8 16 8 35'Quantit:' 8 46
NOART R MODIF
0I
NOMART QUANT
15 7
B 2B
218
Affichage du format SAISIE

Modification d'un article Numro de l'article modifier: 1
Affichage du format MODIF

Libell: un Quantit: 13
Source RPG IV
FECRART CF E WORKSTN C EXFMT SAISIE C IF *IN03 = '0' C* C*RECHERCHE DE L'ENREGISTREMENT C* C/EXEC SQL C+ SELECT NOMART, QUANT INTO :NOMART, :QUANT C+ FROM ART1 C+ WHERE NOART= :NOART C/END-EXEC C* C*VERIFICATION DES ERREURS DE SAISIE C* C IF SQLCODE = 0 C EXFMT MODIF C IF *IN25 C* C*SI UNE MODIFICATION A ETE EFFECTUEE C* C/EXEC SQL C+ UPDATE ART1 C+ SET NOMART = :NOMART, QUANT = :QUANT C+ WHERE NOART= :NOART C/END-EXEC C* C*VALIDATION DE LA TRANSACTION C* C/EXEC SQL C+ COMMIT C/END-EXEC C ENDIF C ENDIF C ENDIF C IF *IN03 C MOVE *ON *INLR C ENDIF
6 - SQL/400
219
220
DDS du fichier ART1

R FART NOART NOMART QUANT K NOART 5 15 7 0 2
Figure 6.2 : programme (en RPG/400 et RPG IV) de modification dun article incluant des requtes SQL. Si ART1 est un fichier non journalis, il faut enlever la ligne contenant lordre COMMIT. Remarquer que les tables traites par SQL ne sont pas dclares en spcification F.
INSERT INTO Cet ordre accompagn de ROWS VALUES permet dinsrer un certain nombre denregistrements en une seule opration. Une variable associe doit contenir les donnes insrer, par exemple :
IDATA DS 5 I.description de la data-structure occurrence multiple ... C*initialisation de la data-structure DATA C... C/EXEC SQL C+ INSERT INTO tab1 C+ 5 ROWS VALUES (:data) C/END-EXEC
insre cinq enregistrements partir du contenu de la data-structure DATA. Il est vident que son organisation doit tre compatible avec les donnes des cinq enregistrements ajouts.
Gestion des erreurs

Des informations sur le droulement de la requte qui vient de sachever nous sont renvoyes dans une structure appeles SQLCA (pour SQL Communications Area). Elle reprsente un ensemble de variables qui sont mises jour aprs lexcution de chaque requte. En RPG cette structure est automatiquement incluse dans le programme (remarquer la data-structure SQLCA de lexemple 6.1).
SQLCODE
est une des informations de la SQLCA, elle permet de savoir comment sest termine la requte. Si :
sa valeur est gale 0, tout sest bien termin ; elle est ngative, une erreur sest produite ;
6 - SQL/400
221
elle est comprise entre 0 et 100, une erreur mineure est survenue. Le SQLCODE peut tre gr par lordre WHENEVER qui est utilis de trois manires : WHENEVER NOT FOUND permet de tester la valeur 100 (utile pour traiter les slections qui renvoient plus dun enregistrement, nous le verrons plus loin) ; WHENEVER SQLERROR pour les valeurs ngatives (donc lies une erreur) ; WHENEVER SQLWARNING pour identifier les incidents mineurs. Une action doit tre associe cet ordre afin de dterminer le traitement effectuer. Cette action peut tre soit dignorer lvnement (CONTINUE), soit de se drouter vers le label cit aprs un GOTO. Par exemple :
C/EXEC SQL C+ WHENEVER SQLERROR GOTO erreur C/END-EXEC
provoque le saut au label ERREUR si une erreur survient ;

C/EXEC SQL C+ WHENEVER SQLWARNING CONTINUE C/END-EXEC
ignore les incidents mineurs. Gnralement, WHENEVER est plac au dbut du source, le test du SQLCODE est ainsi automatiquement ralis aprs toutes les requtes SQL du programme. Il est important de tester le SQLCODE afin dtre sr que tout sest bien pass. Une autre mthode consiste effectuer le contrle sans passer par les fonctions SQL. En RPG, par exemple, la variable correspondante sappelle SQLCOD. Elle est de type numrique, il est donc ais de vrifier si elle est gale 0 pour savoir si la requte sest bien termine. Le traitement associ peut ainsi tre un code opration autre que GOTO qui est une des limites de WHENEVER (exemple 6.2). Dautres informations sont contenues dans la SQLCA, on peut noter que : SQLERRMC (ou SQLERM en RPG) contient les donnes associes au message derreur ; SQLERRD (ou SQLER1 SQLER6 en RPG) renvoie diffrentes informations. Par exemple, SQLER3 en RPG permet de connatre le nombre denregistrements traits par un INSERT, un UPDATE, un DELETE ou un FETCH, SQLER5 donne des indications sur la base de donnes aprs un CONNECT ;
222
SQLSTATE (ou SQLSTT en RPG) contient un code retour et permet de grer les problmes lors daccs des bases de donnes loignes.
Les oprations complexes

Lorsque la requte renvoie un nombre variable denregistrements, il faut utiliser une structure intermdiaire appele curseur. Son utilisation requiert plusieurs tapes qui sont : la dclaration de la requte qui correspond au curseur ; louverture du curseur, c'est--dire le lancement de la requte. Le curseur apparat alors comme une structure contenant les lignes extraites de la base de donnes ; la lecture de ces lignes dans une boucle de traitement.
La dclaration
Lordre DECLARE CURSOR FOR dfinit la requte associe un curseur. Il neffectue aucune action sur les donnes. Par exemple :
C/EXEC SQL C+ DECLARE crs1 CURSOR FOR C+ SELECT zone1, zone2, zone3 C+ FROM tab1 C+ WHERE zone1 = 50 C+ ORDER BY zone2 C/END-EXEC
associe une slection au curseur CRS1.
Ouverture du curseur
Louverture dun curseur par lordre OPEN provoque le lancement de la requte qui lui est associe. Les donnes renvoyes par le SELECT apparaissent alors comme tant places dans le curseur. Elles sont en fait ranges dans une table rsultat, le curseur tant un pointeur sur la ligne courante de cette structure. Selon le type de contrle de validation choisi les enregistrements lus peuvent tre verrouills. Si ce nest pas le cas, les donnes dorigine peuvent tre modifies sans que les mises jour soient rpercutes en direction du curseur. De ce fait, les lignes traites par le programme SQL peuvent ne plus correspondre la ralit du
6 - SQL/400
223
moment.
224
Par exemple :
C/EXEC SQL C+ OPEN crs1 C/END-EXEC
lance la requte associe au curseur CRS1. Le curseur est ferm par lordre CLOSE ou par une fin de transaction (COMMIT, ROLLBACK) si le contrle de validation est actif.
Traitement des donnes

Une fois le curseur ouvert, il faut lire les lignes qui ont t extraites de la base de donnes. Lordre FETCH INTO permet de lire la ligne courante et de placer les donnes dans des variables du programme, par exemple :
C/EXEC SQL C+ FETCH crs1 C+ INTO :zone1, :zone2, :zone3 C/END-EXEC
place le contenu de la ligne courante dans les variables ZONE1, ZONE2 et ZONE3. Pour traiter toutes les donnes renvoyes par la requte, lordre FETCH doit tre plac dans une boucle, la condition de sortie tant SQLCODE gal 100 (il ny a plus de ligne lire). Cette valeur peut tre teste soit par lordre SQL WHENEVER NOT FOUND, soit par les fonctions du langage. Rappellons que cette dernire option est plus puissante car elle est permet le dclenchement de nimporte quel traitement. Toutefois, la description de la SQLCA doit tre ramene dans le programme avec un ordre propre au langage de type :
INCLUDE SQLCA
sauf en RPG o une data-structure est automatiquement dcrite. Lordre WHENEVER NOT FOUND peut tre plac au dbut du programme. Lors de la prcompilation, il est remplac par un test de SQLCODE aprs chaque ordre SQL (de type SELECT, FETCH, INSERT INTO, UPDATE et DELETE). Sil a une valeur de 100, alors le programme se droute vers le label qui lui est associ.
6 - SQL/400
225
Algorithme gnral
Voici lalgorithme dun programme type utilisant un curseur :
/*Dclaration des variables*/ ... /*Dclaration du curseur*/ EXEC SQL DECLARE crsx CURSOR FOR SELECT zonex, zoney FROM tabx WHERE zonex = y ORDER BY zonex END-EXEC /*Eventuellement gestion de la condition de fin par SQL*/ /*Cet appel peut tre remplac par des tests de SQLCODE*/ EXEC SQL WHENEVER NOT FOUND GOTO fin END-EXEC /*Ouverture du curseur*/ EXEC SQL OPEN crsx END-EXEC lecture: EXEC SQL FETCH crsx INTO :zonex, :zoney END-EXEC /*Traitement des donnes*/ GOTO lecture fin: /*Traitement de fin*/ EXEC SQL CLOSE crsx END-EXEC
Dans le cas o des modifications sont apportes la base de donnes, lordre CLOSE peut tre remplac par une validation (COMMIT).
Exemple
Lexemple 6.3 sappuie sur lalgorithme que nous venons de dfinir. Le test de SQLCODE par les fonctions du langage a t choisi la place de WHENEVER car il permet de rester dans une programmation de type structure.
226

FECRART CF E WORKSTN C* C*DECLARATION DU CURSEUR C* C/EXEC SQL C+ DECLARE CRS1 CURSOR FOR C+ SELECT NOMART, QUANT, NOART C+ FROM ART1 C/END-EXEC C* C*OUVERTURE DU CURSEUR C* C/EXEC SQL C+ OPEN CRS1 C/END-EXEC C* C*BOUCLE DE LECTURE DES ENREGISTREMENTS C* C SQLCOD DOUEQ100 C *IN03 OREQ '1' C/EXEC SQL C+ FETCH CRS1 INTO :NOMART, :QUANT, :NOART C/END-EXEC C* C SQLCOD IFNE 100 C EXFMTMODIF2 C *IN25 IFEQ '1' C* C*SI UNE MODIFICATION A ETE EFFECTUEE C* C/EXEC SQL C+ UPDATE ART1 C+ SET NOMART = :NOMART, QUANT = :QUANT C+ WHERE CURRENT OF CRS1 C/END-EXEC C ENDIF C ENDIF C ENDDO C* C*VALIDATION DE LA TRANSACTION C* C/EXEC SQL C+ COMMIT C/END-EXEC C MOVE *ON *INLR
Affichage du format MODIF2

Numro: 1234 Libell: un Quantit: 13
6 - SQL/400
227

R MODIF2 8 8 8 8 8 8 CHANGE(25 'Modification') 2'Numro:' 10 16'Libell:' 26 45'Quantit:' 56
NOART NOMART QUANT
5 15 7
0O B 2B
Exemple 6.3 : programme RPG/400 affichant les enregistrements dune table un par un et autorisant la modification. Il sappuie sur lexemple 6.2. La validation par SQL est effectue une seule fois la sortie du programme.
Optimisations lies au curseur

Certaines dclarations peuvent accrotre les performances des requtes SQL. Elles sont toutefois utiliser avec prudence, en toute connaisance de cause.
En lecture
Lors de la dclaration du curseur, on peut indiquer SQL que les donnes ramenes seront uniquement lues, il pourra ainsi les traiter par blocs (FOR FETCH ONLY). La clause OPTIMIZE prcise que la stratgie daccs devra tre optimise pour un certain nombre de lignes. Par exemple :
C/EXEC SQL C+ DECLARE crs1 CURSOR FOR C+ SELECT zone1, zone2, zone3 C+ FROM tab1 C+ FOR FETCH ONLY C+ OPTIMIZE FOR 5 ROWS C/END-EXEC
optimise la requte pour 5 lignes ; les donnes seront utilises en lecture uniquement. Il faut noter quil est inutile de citer FOR FETCH ONLY quand la table rsultat ne peut tre traite quen lecture, notamment lorsque : plusieurs tables ou vues sont cites dans le FROM ; la clause DISTINCT est cite dans le SELECT principal ; des fonctions de colonnes sont utilises dans le SELECT principal.
228
La lecture des donnes partir de la table rsultat peut se faire par blocs de plusieurs lignes ; il faut alors prvoir une structure capable de les recevoir. Lordre FETCH curseur FOR x ROWS INTO :var permet de lire x lignes et de les placer dans la structure de donnes VAR. Par exemple :
C/EXEC SQL C+ FETCH crs1 FOR 3 ROWS INTO :enreg3 C/END-EXEC
lit trois lignes partir de la table rsultat et les place dans ENREG3. En RPG, cette variable peut tre une data-structure occurrences multiples dfinie de la manire suivante : en RPG/400
IENREG3 I I DS 3 1 11 10 ZONE1 20 ZONE2
en RPG IV
Denreg3 D zone1 D zone2 DS 10 10 OCCURS(3)
Enfin, il est important de signaler que le nombre de lignes rellement lues est plac dans SQLERRD3 (SQLER3 en RPG/400) de la SQLCA. Il faut tester cette valeur afin de connatre le nombre exact denregistrements traiter.
En modification
Lordre FOR UPDATE OF permet de prciser le nom des colonnes qui pourront tre modifies pour nimporte lequel des enregistrements renvoys. Par dfaut, toutes les colonnes cites dans le SELECT sont modifiables si : elles ne sont pas nommes dans la clause ORDER BY, auquel cas FOR UPDATE OF est indispensable ; FOR FETCH ONLY nest pas prcis ; la table ou la vue nest pas en lecture seulement. Une colonne qui napparat pas dans le SELECT peut tre modifie si elle est dfinie par FOR UPDATE OF.
6 - SQL/400
229
230
Par exemple :
C/EXEC SQL C+ DECLARE crs1 CURSOR FOR C+ SELECT zone1, zone2 C+ FROM tab1 C+ ORDER BY zone1 C+ FOR UPDATE OF zone1, zone3 C/END-EXEC
permet la modification, pour chaque ligne renvoye, des colonnes ZONE1 et ZONE3, mme si cette dernire napparat pas dans le SELECT. La modification de la ligne courante (celle qui a t extraite de la table rsultat par le dernier FETCH) est dclenche avec lordre UPDATE dans lequel on spcifie WHERE CURRENT OF suivi du nom du curseur. Lexemple 6.3 en est lillustration. La modification de la ligne courante ne modifie pas le pointeur associ au curseur. Pour passer lenregistrement suivant il faut utiliser nouveau lordre FETCH.
En insertion
Comme pour la lecture, linsertion de lignes peut tre effectue par blocs. Par exemple :
C/EXEC SQL C+ INSERT INTO tab1 C+ 3 ROWS VALUES(:ENREG3) C/END-EXEC
insre trois enregistrements correspondant chacun une occurence de la datastructure ENREG3. Il est l aussi essentiel de tester la SQLCA pour vrifier que linsertion sest correctement droule.
Dplacement contrl dans le curseur

Jusque-l, nous avons trait les lignes de la table rsultat dans lordre o elles taient renvoyes par la requte, FETCH tant assimil un ordre de lecture squentielle. DECLARE SCROLL CURSOR dfinit un curseur qui permet de se dplacer dans la table rsultat dans le sens souhait (avant ou arrire) ou de se positionner sur une ligne particulire (dbut, fin...). Ce curseur ne peut tre utilis que pour des lectures de donnes. DYNAMIC associ SCROLL permet la modification des enregistrements travers le curseur.
6 - SQL/400
231
Par exemple :
C/EXEC SQL C+ DECLARE crs1 DYNAMIC SCROLL CURSOR FOR C+ SELECT zone1, zone2 C+ FROM tab1 C/END-EXEC
Un mot-cl associ lordre FETCH dfinit la position de la ligne lire. Voici la liste de ces mots-cls :
Mot-cl
AFTER BEFORE CURRENT FIRST LAST NEXT PRIOR RELATIVE
Description Positionnement aprs la dernire ligne Positionnement avant la premire ligne Ne change rien Lecture de la premire ligne Lecture de la dernire ligne Lecture de la ligne suivante (cest la valeur par dfaut) Lecture de la ligne prcdente Se positionne en fonction dune variable ou dune valeur numrique. Par exemple, -1 provoque la lecture de la ligne prcdente et +1 de la suivante
Exemples
Ces deux exemples doivent tre prcds par la dclaration dun curseur contenant le mot-cl SCROLL.
C/EXEC SQL C+ FETCH PRIOR FROM crs1 C+ INTO :zone1, :zone2, :zone3 C/END-EXEC
place le contenu de la premire ligne dans les variables ZONE1, ZONE2 et ZONE3.
C/EXEC SQL C+ FETCH RELATIVE :cpt FROM crs1 C+ INTO :zone1, :zone2, :zone3 C/END-EXEC
se positionne en fonction du contenu de la variable CPT.
SQL dynamique
La requte SQL peut tre dfinie au dernier moment selon le choix dun utilisateur ou en fonction de lenvironnement. Cest une possibilit importante de ce langage qui permet de raliser des applications qui ne peuvent ltre en RPG ou Cobol.
232
Les oprations effectuer par le programmeur ne sont pas les mmes selon que les requtes contiennent un SELECT ou un autre ordre, et selon que les colonnes sont connues au moment de la compilation ou sont choisies au dernier instant, au cours de lexcution du programme.
Slection
Il est parfois utile de donner lutilisateur la possibilit de choisir ses propres critres de slection ou de tri tout en lui imposant la table et les colonnes quil peut grer. Les colonnes qui seront ramenes par la requte sont connues au moment de la compilation. La ralisation de telles applications est relativement simple ; lalgorithme du programme peut tre rsum ainsi : dfinir les lments manquants de la requte (demander, par exemple, lutilisateur dindiquer ses critres de slection et de tri) ; constituer le texte de la requte grce une data-structure ; prparer la requte avec lordre PREPARE ; dclarer le curseur de manire classique (DECLARE) ; ouvrir le curseur et traiter les lignes extraites comme pour une application SQL statique. Lexemple 6.4 prsente un programme qui demande lutilisateur de choisir les caractristiques des enregistrements traiter. DDS du format REQUETE
R REQUETE 1 30'Critres de slection:' 4 7'WHERE:' 4 15
WHERE
37
Affichage du format REQUETE et exemple de saisie

Critres de slection:
WHERE:
NOART > 3 ORDER BY NOART
6 - SQL/400
233

FECRART CF E WORKSTN I DS I 1 I I 'SELECT NOMART,QUANT,1 I ' NOART FROM ART1 I 'WHERE ' I 44 C* C*DEMANDE DU CRITERE DE SELECTION C* C EXFMTREQUETE C* C*PREPARATION DU CURSEUR C* C/EXEC SQL C+ PREPARE REQUEST FROM :REQ C/END-EXEC C* C*DECLARATION DU CURSEUR C* C/EXEC SQL C+ DECLARE CRS1 CURSOR FOR REQUEST C/END-EXEC C* C*OUVERTURE DU CURSEUR C* C/EXEC SQL C+ OPEN CRS1 C/END-EXEC C* C*BOUCLE DE LECTURE DES ENREGISTREMENTS C* C SQLCOD DOUEQ100 C *IN03 OREQ '1' C/EXEC SQL C+ FETCH CRS1 INTO :NOMART, :QUANT, :NOART C/END-EXEC C* C SQLCOD IFNE 100 C EXFMTMODIF2 C *IN25 IFEQ '1' C* C*SI UNE MODIFICATION A ETE EFFECTUEE C* C/EXEC SQL C+ UPDATE ART1 C+ SET NOMART = :NOMART, QUANT = :QUANT C+ WHERE CURRENT OF CRS1 C/END-EXEC
80 REQ 43 SELECT
80 WHERE
234
C* C*VALIDATION DE LA TRANSACTION C* C/EXEC SQL C+ COMMIT C/END-EXEC C ENDIF C ENDIF C ENDDO C*FIN DU PROGRAMME C MOVE *ON
*INLR
Exemple 6.4 : mise en uvre dun SELECT dynamique. Il sappuie sur lexemple 6.3. La saisie propose permet de modifier les enregistrements dont le numro darticle est suprieur 3. Les articles apparatront tris sur la colonne NOART.
Si les colonnes ne sont pas connues au moment de la compilation, le traitement est plus complexe car il faut rcuprer des informations de type Pointeur dans une structure appele SQLDA. Cela est impossible en RPG/400 mais support en RPG IV. Le traitement de ces informations est relativement fastidieux et sort du cadre de cet ouvrage.
Autres Requtes
Si tous les ordres SQL ne peuvent pas tre utiliss en dynamique, les principaux sont toutefois notre disposition (CREATE, DROP, COMMIT, ROLLBACK, DELETE, INSERT, UPDATE, GRANT, REVOKE). Parmi ceux proscrire, on peut noter CONNECT et dans certains cas SELECT INTO. Sans paramtres Si la requte est totalement dfinie dans une variable du programme, elle peut tre lance par un ordre EXECUTE IMMEDIATE. On peut ainsi demander un utilisateur de taper sa propre requte dans une zone de saisie de type Alphanumrique. Celleci ne peut extraire des donnes car lordre SELECT INTO est interdit. Lexemple 6.5 propose un utilisateur de saisir sa requte et lexcute. Par soucis de lisibilit, la saisie est sans contrle. DDS du fichier daffichage ECRSQL
R REQUETE DSPSIZ(24 80 *DS3) CA03(03) 1 30'Saisie de la requte:' 4 2'Requte:' 4 11
REQ
100
6 - SQL/400
235
236
Affichage du format REQUETE et exemple de saisie

Saisie de la requte:
Requte: CREATE TABLE COL1.ART2 (Z1 CHAR(10) NOT NULL, Z2 CHAR(5) NOT NULL)
Exemple RPG/400
FECRSQL CF E WORKSTN * C*SAISIE DE LA REQUETE C EXFMTREQUETE C* C*EXECUTION IMMEDIATE C* C/EXEC SQL C+ EXECUTE IMMEDIATE :REQ C/END-EXEC C MOVE *ON *INLR
Exemple 6.5 : excution immdiate dune requte SQL dynamique.
Lors dune excution immdiate, la requte tant comme interprte, loptimiseur na pu prparer aucune action. Avec paramtres Une partie de la requte peut tre connue lors de la compilation. On sait, par exemple, que lon va effectuer la suppression dun enregistrement mais la valeur du critre de slection ne sera connue quau dernier moment, par lintermdiaire dune variable du programme. Lalgorithme du programme peut alors se rsumer : initialisation dune variable contenant le texte connu de la requte, les emplacements des donnes variables tant dfinis par le caractre ? ; prparation de la requte avec lordre PREPARE ; excution de la requte avec lordre EXECUTE USING. Les points dinterrogation sont alors automatiquement remplacs, dans lordre, par le contenu des variables cites aprs USING. Lexemple 6.6 prsente un programme qui dtruit un enregistrement dans la table ART1 dfinie dans les exemples prcdents.
6 - SQL/400
237

R DEL DSPSIZ(24 80 *DS3) CA03(03) 1 26' Suppression d''enregistrement 3 6'Numro d''enregistrement + dtruire:' 3 42
NOART
0I
Affichage du format DEL et exemple de saisie

Suppression d'enregistrement Numro d'enregistrement dtruire: 12345

FECRSQL CF E WORKSTN I DS I I 'DELETE FROM ART1 1 I 'WHERE NOART = ?' C* C*DEMANDE DE L'ENREGISTREMENT A DETRUIRE C* C EXFMTDEL C *IN03 IFEQ *OFF C* C*PREPARATION DU CURSEUR C* C/EXEC SQL C+ PREPARE REQUEST FROM :REQT C/END-EXEC C* C*EXECUTION C* C/EXEC SQL C+ EXECUTE REQUEST USING :NOART C/END-EXEC C* C*VALIDATION DE LA TRANSACTION C* C/EXEC SQL C+ COMMIT C/END-EXEC C ENDIF C*FIN DU PROGRAMME C MOVE *ON *INLR
32 REQT
Exemple 6.6 : destruction dun enregistrement par un programme SQL dynamique.
238
6 - SQL/400
239
Optimisations
De trs nombreux lments intervenant sur les performances des requtes SQL, nous citerons les principaux, indispensables une bonne gestion de SQL/400.
Loptimiseur
Loptimiseur est une des composantes essentielles de la base de donnes DB2/400. Il doit dterminer quelle est la manire la plus rapide pour accder aux donnes. Il nest pas propre SQL mais est utilis par tous les produits tels que Query/400, PCS/400, Client Access/400 et par la commande OPNQRYF. En fait, ils sappuient tous sur le mme moteur daccs aux donnes. Ce nest pas le cas pour les programmes classiques (nincluant pas SQL), qui attaquent directement la base de donnes. Lors de lexcution dun programme contenant des requtes SQL, loptimiseur dtermine la meilleure stratgie pour accder aux donnes. Il envisage, par exemple : la lecture squentielle des enregistrements ; lutilisation dun index ou dun chemin daccs existant ; la cration dun index temporaire. Il sappuie aussi sur le modle dAS/400, sur le nombre denregistrements traiter et mme sur des statistiques du systme. Les plans daccs sont des structures associes un programme contenant du SQL. Chacun comporte toutes les indications pour accder aux tables et vues dune requte (il indique notamment la prsence dun index). Il contient un miniplan visible lorsque lon effectue le dump dun programme par la commande DMPOBJ. Si la requte est statique, le plan daccs est dfini lors de la compilation et peut tre ventuellement rvis lors de lexcution car lenvironnement peut avoir volu (un nouvel index a-til t cr ?). Pour du SQL dynamique, il ne peut tre gnr que lorsque tous les lments sont connus. Les plans daccs composent les packages, objets de type *SQLPKG, qui sont transmis au systme distant lors de lutilisation dune base de donnes loigne dans le cadre de DRDA.
240
Enfin, rappellons que certains ordres SQL peuvent aider loptimiseur choisir les bonnes solutions (section Optimisations lies au curseur, de ce chapitre).
Les index
SQL peut accder aux donnes dune table soit en squentiel, toutes les lignes sont alors lues, soit directement partir dun index (ou chemin daccs), sil existe. De ce fait, les index constituent lun des lments de base de loptimisation de SQL. Ils doivent tre crs chaque fois que cela est ncessaire, par lordre CREATE INDEX ou en mme temps que les fichiers physiques ou logiques avec cls, par les commandes CRTPF et CRTLF. Dans certains cas, si le chemin daccs nexiste pas, SQL peut tre amen le reconstruire. Si le fichier est gros, les temps de rponses peuvent tre dsastreux. Un index est systmatiquement utilis dans les situations suivantes : lorsque les ordres GROUP BY ou ORDER BY sont cits ; lors de jointures. La dfinition du critre de slection (WHERE) est aussi un lment important, car il peut conditionner lutilisation dun index existant. Si LIKE est cit, par exemple, lindex ne pourra pas tre utilis si un caractre de substitution (% ou _) est plac en premier. Il est aussi important de dfinir les valeurs de comparaison avec les mmes caractristiques que la colonne sur laquelle sappuie lindex. Si, par exemple, celle-ci est de type Alphanumrique de longueur 5 on prfrera :
WHERE nocli = 123
plutt que :
WHERE nocli = 123
SQL dynamique
Il est vident que pour une requte SQL dynamique, la partie du travail qui na pu tre ralise lors de la compilation le sera lors de lexcution. Les temps de rponse sont donc dgrads par rapport la mme requte dfinie en statique. On essaiera donc de limiter lutilisation de SQL dynamique aux seuls cas o cela est indispensable.
La commande CHGQRYA
6 - SQL/400
241
La commande CHGQRYA apparue avec le V3R1M0 de lOS/400 permet de limiter les possibilits dun travail en lui interdisant les requtes abusives. La paramtre QRYTIMLMT prcise le temps CPU que pourra consommer une requte. Si loptimiseur prvoit une valeur suprieure, le message CPA4259 est renvoy QSYSOPR lui demandant de continuer ou darrter cette action. Des informations sur le plan daccs utilis par la requte accompagnent ce message. Cette commande permet aussi dautoriser le paralllisme, cest--dire que plusieurs bras daccs disques peuvent tre mobiliss en mme temps pour accder aux donnes dun fichier. Ainsi, le processeur nattend plus que les donnes soient disponibles pour ce travail, ce qui peut amliorer nettement ses performances (tout en dgradant aussi nettement celles des autres travaux !).
La commande PRTSQLINF
La commande PRTSQLINF est apparue avec la V3R1M0 de lOS/400. Elle gnre un fichier spoule contenant des informations sur un programme contenant du SQL. On y trouve notamment la liste des requtes et les options de compilation.
Conclusions sur SQL/400

La question que se posent de nombreux responsables informatique est de savoir sil faut utiliser SQL/400 ou continuer avec les classiques READ et WRITE du RPG. Les avantages de SQL sont nombreux, nous pouvons citer : cest un standard universellement reconnu qui assure une excellente portabilit ; cest un langage connu par un trs grand nombre de dveloppeurs. Les jeunes diplms en informatique, notamment, ont gnralement suivis des cours sur ce sujet ; il autorise laccs des bases de donnes distantes et htrognes ; il permet la ralisation dapplications laissant lutilisateur la possibilit de dfinir tout ou partie de la requte grce au SQL dynamique ; il dispose de plusieurs interfaces : interactive, batch, Query Manager et prcompilateur pour tre inclus dans des programmes ; avec une collection, cest un environnement automatiquement scuris avec la journalisation et mme, ventuellement, avec le contrle de validation ;
242
il est idal pour le traitement de masse. Augmenter le prix de tous les articles de 10 % est une opration trs simple en SQL. Parmi les inconvnients, on lui reproche souvent : dtre relativement peu performant, mais il samliore de version en version et les critiques mises son origine ne sont plus vraiment dactualit ; de ne pas tre dans la culture des informaticiens spcialistes des mini IBM (34, 36, 38). Il appartient chacun de se faire une opinion en fonction des ses besoins et de ses contraintes. Il est toutefois vident que SQL/400 apparat aujourdhui comme un produit stratgique pour IBM, chaque nouvelle annonce sur lAS/400 le confirmant.
Les principaux ordres SQL

CREATE TABLE CREATE COLLECTION SELECT CLOSE COMMIT CONNECT CREATE INDEX CREATE SCHEMA
CREATE VIEW DECLARE CURSOR DELETE DROP EXECUTE
EXECUTE IMMEDIATE FETCH GRANT INSERT
cre une table ; cre une collection ; extrait des enregistrements ; ferme un curseur ; valide une transaction ; se positionne sur une base de donnes distante ; cre un index ; cre en une seule requte tout un environnement SQL (collection, tables, index, vues, autorisations...) ; cre une vue ; dfinit un curseur ; dtruit un enregistrement ; dtruit un objet SQL (table, vue, collection...) ; lance une requte prpare dynamiquement en utilisant ventuellement des variables du programme comme des paramtres ; prpare et excute une requte dynamique ; lit une ligne (ou une srie de lignes) dans la table rsultat par lintermdiaire dun curseur ; accorde une autorisation ; insre un enregistrement ou une srie denregistrements groups ;
6 - SQL/400
243
OPEN PREPARE REVOKE ROLLBACK UPDATE WHENEVER
ouvre un curseur, cest--dire lance la requte associe ; prpare une requte dynamique ; enlve une autorisation ; invalide une transaction ; met jour un enregistrement ; teste une condition particulire et droute le programme vers un label.

CHGQRYA CRTSQLRPG CRTSQLRPGI PRTSQLINF RUNSQLSTM STRSQL
permet dinterdire les requtes abusives consommant trop de CPU ; cre une programme RPG/400 contenant du SQL ; cre une programme RPG IV contenant du SQL ; donne des indications sur la stratgie daccs dun programme contenant des requtes SQL ; lance linterprteur SQL batch ; lance linterprteur SQL interactif.

CMDSQL.
244
SQL/400.............................................................................................................................185 INTRODUCTION ...................................................................................................................185 LENVIRONNEMENT SQL ....................................................................................................186 Terminologie ..................................................................................................................187 Le catalogue...................................................................................................................187 Conventions SQL............................................................................................................187 Utiliser une collection ou non ? .....................................................................................188 LES ELEMENTS DU LANGAGE SQL.......................................................................................190 Les environnements dexcution ....................................................................................190 Les conventions ..............................................................................................................192 La dfinition des structures SQL ....................................................................................192 La gestion des donnes...................................................................................................198 Les registres spciaux ....................................................................................................207 Le contrle de validation ...............................................................................................209 La scurit......................................................................................................................209 La connexion une base de donnes loigne...............................................................210 SQL DANS LES PROGRAMMES .............................................................................................212 Principes ........................................................................................................................213 Les variables locales ......................................................................................................216 Les oprations simples ...................................................................................................216 Les oprations complexes...............................................................................................222 Optimisations lies au curseur .......................................................................................227 Dplacement contrl dans le curseur...........................................................................230 SQL dynamique ..............................................................................................................231 OPTIMISATIONS ...................................................................................................................239 Loptimiseur ...................................................................................................................239 Les index ........................................................................................................................240 SQL dynamique ..............................................................................................................240 La commande CHGQRYA..................................................................................................240 La commande PRTSQLINF ................................................................................................241 CONCLUSIONS SUR SQL/400...............................................................................................241 LES PRINCIPAUX ORDRES SQL ............................................................................................242 LES PRINCIPALES COMMANDES ...........................................................................................243 LES PRINCIPAUX MENUS ......................................................................................................243
A
ADDPFCST 193; 195 ADDRDBDIRE 204 ALTER TABLE 193; 195 AND 196 BETWEEN
B
197
C
CHGQRYA 227 CHGRDBDIRE 204
186
Client Acces/400 226 collection 188 COMMIT 188; 203; 205; 208; 215 CONNECT 205 CREATE
COLLECTION 191 INDEX 193 SCHEMA 194 TABLE 192 VIEW 193
CRTLF 227 CRTPF 227 CRTSQLCOL
GRANT 203 GROUP BY 199; 227 GRTOBJAUT 203
H
HAVING
199
I
197 index 193; 227 INSERT INTO 201
IN
188
curseur 213
D
213; 221 DELETE 202 DFTRDBCOL 191 dictionnaire 191 DISTINCT 196; 217 DMPOBJ 226 DRDA 185; 226 DROP 195 DSPOBJAUT 203 DYNAMIC 219
DECLARE
L
lordre CREATE INDEX 227 LIKE 197; 227
M
miniplan 226
N
NAMING 191 NULL 192; 197
E
EDTOBJAUT 203 END-EXEC 206 OPEN 213 OPNQRYF 226
O
optimiseur 226
OPTIMIZE 217 OR 196 ORDER BY 197;
erreur 211
EXECUTE
IMMEDIATE USING
223
224
218; 227
F
FETCH 214; 218 FOR FETCH ONLY 217 FOR UPDATE OF 218 FROM 196; 199; 217
P
par COUNT(*) 198 PCS/400 226 plans daccs 226 PREPARE 221; 224 PRTSQLINF 228
G
GOTO
212
6 - SQL/400
187
Q
QSQJRN 191 QSQLTEMP 206 QSYS 187 QSYSOPR 228 QSYSPRT 206 QTEMP 206
Query 226 Query Manager 189 Query/400 189
R
204 Rexx 205 ROLLBACK 203; 205 ROWS VALUES 211 RPG IV 205 RPG/400 205 RUNSQLSTM 188; 190; 203 RVKOBJAUT 203
REVOKE
scurit 203 SELECT 195; 213; 217; 221 SELECT INTO 208; 223 SGBD 205 SQL 185 SQL/400 185 SQLCA 211; 214; 218 SQLCBL 206 SQLCODE 211 SQLDA 223 SQLRPG 206 SQLRPGLE 206 STRCMTCTL 203 STRQM 189 STRQMQRY 190 STRSQL 188; 189; 203 SYSTABLES 196
U
UPDATE 201; 219
S
SBMJOB SCROLL
W
WHENEVER 212 WHERE 196; 200; 227 WRKRDBDIRE 204
190 219
Chapitre 7
Gestion de la base de donnes
LOS/400 met notre disposition diverses commandes lies la base de donnes qui sont indispensables la gestion courante des fichiers et des programmes. Elles permettent dditer des rfrences croises, dutiliser les membres et de faciliter encore plus laccs aux donnes. Les API sont des programmes et procdures qui permettent de dvelopper des applications avances. Certaines ont un rapport avec la base de donnes. Ces diffrents thmes sont abords dans ce chapitre fourre-tout qui apporte une vision plus large de DB2/400.
La commande OPNQRYF
La commande OPNQRYF (Open Query File) peut tre considre comme une extension des fichiers logiques car elle cre une structure temporaire permettant de voir des enregistrements. Mais elle est beaucoup plus puissante de nombreux titres : elle ne sappuie pas sur des DDS qui sont figes dans un membre source. Les caractristiques des donnes sont dfinies au dernier moment dans ses paramtres. Son utilisation est donc extrmement souple ; les donnes sont vues partir de fichiers physiques et logiques. On obtient donc une structure comparable un fichier logique qui peut sappuyer sur des fichiers logiques ;
elle possde des fonctions de traitement de chanes de caractres et de nombreuses fonctions mathmatiques ; elle permet de dfinir des zones qui sont le rsultat dun calcul sur dautres zones ; elle autorise le traitement de zones rcapitulatives ; elle sappuie sur le mme optimiseur que SQL et utilise donc tous les chemins d'accs et tous les index existants ; enfin, elle peut aussi renvoyer les donnes vers un fichier physique. La structure cre par cette commande est souvent nomme Open Query File. Je reprendrai cette appellation. Il faut avoir lesprit que si les fichiers sous-jacents sont gros, le temps de mise en place de lOpen Query File peut tre long et les ressources consommes importantes, car le systme rcupre dynamiquement les enregistrements lors de lexcution de la commande OPNQRYF. Cest un des inconvnients de cette fonction, surtout en interactif.
Principes
La commande OPNQRYF cre dynamiquement une structure temporaire permettant de voir des donnes. Elle est cre quand on en a besoin et peut tre dtruite quand elle est devenue inutile. Avant de lancer cette commande il faut effectuer un certain nombres doprations de manire prparer lenvironnement (figure 7.1). Il faut tout dabord compiler le programme qui doit utiliser l'Open Query File en sappuyant sur un fichier de mme format. La structure rsultant de la commande OPNQRYF tant temporaire, le compilateur ne peut sen servir pour ramener la description des zones. Il doit donc sappuyer sur un autre fichier. Si l'Open Query File est utilis seulement pour extraire une slection denregistrements correspondant certains critres, le fichier vu par le programme peut tre le fichier partir duquel on traite les donnes. Sinon, c'est--dire chaque fois que l'Open Query File a un format diffrent du fichier qui est lorigine des donnes, il faut crer un fichier intermdiaire, ne contenant aucune donne, mais ayant le mme format que l'Open Query File. Ce fichier permet au compilateur de ramener dans le programme la description de toutes les zones. Cest le cas chaque fois que la commande OPNQRYF sappuie sur
232
plusieurs fichiers ou quelle modifie les caractristiques des zones (agencement, ajout, suppression...).
1 - Compilation du programme
ODP *PGM
2 - Partage de lODP et cration de l'Open Query File
*FILE
ODP
*PGM
Partage OVRDBF SHARE(*YES)
*FILE
OPNQRYF Cration
Open query file
Figure 7.1 : organisation dune application utilisant la commande OPNQRYF.
La commande OVRDBF permet de substituer le fichier connu du programme par l'Open Query File. Pour se faire, ces deux structures doivent partager le mme ODP, le paramtre SHARE(*YES) doit donc tre spcifi pour cette commande. Il suffit alors dexcuter la commande OPNQRYF en dfinissant les caractristiques des enregistrements ramener. La structure temporaire est cre, le programme de traitement des donnes peut tre lanc. Grce au partage de lODP, il croit attaquer le fichier avec lequel il a t compil mais il traite, en fait, les enregistrements vus par l'Open Query File. Une fois le travail sur les enregistrements termin, l'Open Query File peut tre dtruit par la commande CLOF et la substitution peut tre enleve par un DLTOVR. L'Open Query File est toujours mis en place partir dun programme en langage de contrle (il peut aussi tre dfini partir des API mais nous oublierons cette possibilit !). Lexemple 7.1 prsente un programme qui lance un Open Query File simple, c'est--dire quil a le mme format que le fichier sous-jacent.
233
PGM /*PARTAGE DE L'ODP*/ OVRDBF
FILE(FICH1) SHARE(*YES)
/*DEFINITION ET LANCEMENT DE L'OPNQRYF*/ OPNQRYF FILE((FICH1)) QRYSLT('zone1 *EQ 50') /*LANCEMENT DU PROGRAMME DE TRAITEMENT DES DONNEES*/ CALL PGM(PGMXX) /*FERMETURE DE L'OPNQRYF*/ CLOF OPNID(FICH1) /*DESTRUCTION DU PARTAGE DE L'ODP*/ DLTOVR FILE(FICH1) ENDPGM
Exemple 7.1 : structure dun programme en langage de contrle mettant en place un Open Query File. Le programme de traitement des donnes (PGMXX) utilise le fichier FICH1 qui contient les donnes et qui a le mme format que l'Open Query File.
Lorsque la commande OPNQRYF sappuie sur plusieurs fichiers, il faut crer un fichier qui a le mme format que l'Open Query File et qui servira uniquement la compilation. Dans le programme en langage de contrle, lappel des commandes OVRDBF et OPNQRYF est un peu plus complexe (figure et exemple 7.2).
F*Programme de traitement des donnes FFMTOQF ...
PGM OVRDBF FILE(FMTOQF) TOFILE(FICH1) SHARE (*YES) OPNQRYF FILE(FICH1 FICH2) FORMAT(FMTOQF) ..... CALL PGMxx
Figure 7.2 : organisation dun Open Query File complexe. Le fichier FMTOQF est cr pour la compilation du programme de traitement des donnes. Il est substitu par le premier fichier utilis dans la commande OPNQRYF.
PGM /*Partage de l'ODP*/
234
/*Le fichier connu du programme est substitu par le + premier fichier utilis dans l'Open Query File */ OVRDBF FILE(FICHOQF) TOFILE(FICH1) SHARE(*YES) /*DEFINITION ET LANCEMENT DE L'OPNQRYF*/ OPNQRYF FILE((FICH1) (FICH2)) FORMAT(FICHOQF) + JFLD((FICH1/ZONE1 FICH2/ZONE1 *EQ)) /*LANCEMENT DU PROGRAMME DE TRAITEMENT DES DONNEES*/ /*IL UTILISE LE FICHIER FICHOQF*/ CALL PGM(PGMXX) /*FERMETURE DE L'OPNQRYF*/ CLOF OPNID(FICH1) /*DESTRUCTION DU PARTAGE DE L'ODP*/ DLTOVR FILE(FICH1) ENDPGM
Exemple 7.2 : structure dun programme en langage de contrle mettant en place un Open Query File. Une jointure est ralise entre FICH1 et FICH2 sur ZONE1. FICHOQF sert indiquer le format de l'Open Query File au programme PGMXX.
Les principaux paramtres

Les paramtres de la commande OPNQRYF permettent dintervenir sur de nombreux critres de slection, sur des jointures, sur la cration de zones rsultat... Ils montrent la puissance et la souplesse de cette commande.
Slection denregistrements
LOpen Query File ne laissera voir que les enregistrements qui correspondent aux critres de slections dfinis au travers du paramtre QRYSLT, par exemple :
OPNQRYF FILE(FICH1) QRYSLT(ZONE1
*EQ MONTPELLIER )
ne slectionne que les enregistrements qui ont ZONE1 gal MONTPELLIER. La syntaxe utilise pour codifier le critre de slection associ au paramtre QRYSLT est relativement complexe. Dune manire gnrale, il doit tre plac entre apostrophes() et les chanes de caractres doivent tre dfinies entre des guillemets ().
235
Voici dautres exemples :

*GT 50)
ne laisse voir que les enregistrements tels que ZONE2 est suprieur 50 ;
*EQ %WLDCRD_O*L* )
slectionne les enregistrements qui ont pour ZONE1 un O en deuxime position puis un L nimporte o aprs le O ;
*EQ %CURDATE)
renvoie les enregistrements tels que ZONE1 contienne la date du jour. ZONE1 est de type Date ;
*CT MONT )
extrait les enregistrements qui contiennent MONT nimporte o dans ZONE1. Ne pas confondre loprateur *EQ qui implique une galit totale avec *CT qui demande que la sous-chane soit contenue partir dune position quelconque de la zone. De trs nombreux exemples pourraient tre ajouts cette liste car le paramtre QRYSLT est extrmement puissant. Il permet notamment dutiliser des variables du langage de contrle, dispose de nombreuses fonctions mathmatiques, de plusieurs oprateurs arithmtiques et apporte des possibilits de traitement des chanes de caractres.
La dfinition de nouvelles zones

Des zones nexistant pas dans le (ou les) fichier(s) dorigine(s) peuvent tre cre dans lOpen Query File pour diverses raisons : pour des raisons de compatibilits avec le programme pour qui elles sont dfinies dans le format ; pour permettre de faire une slection sur ces zones ; pour gnrer des donnes rcapitulatives sur les enregistrements renvoys ; et ventuellement pour renommer une zone dont le nom est ambigu car prsent dans plusieurs fichiers. Le paramtre MAPFLD permet de dfinir une nouvelle zone.
236
Par exemple :
MAPFLD((AN OPNQRYF FILE(FICH1) FORMAT(FMT1) ZONE1) (TTC HT * TVA) (SIN %SIN(ZONE2)))
ajoute les trois nouvelles zones AN et TTC et SINUS dont la description figure dans le fichier FMT1. AN contient les donnes de ZONE1, TTC reoit le produit des zones HT et TVA et SIN correspond au sinus de ZONE2.
Les traitements de groupes

LOpen Query File peut nous renvoyer des donnes rcapitulatives sur des groupes denregistrements. Le paramtre GRPFLD dfinit la zone sur laquelle est effectue le groupage la manire du GROUP BY de SQL. Des fonctions mathmatiques permettent de connatre la somme (%SUM), le nombre (%COUNT), lcart type (%STDDEV), la variance (%VAR) et la plus grande (%MAX) ou la plus petite (%MIN) des valeurs dune zone renvoye, par groupe denregistrements. Ainsi :
OPNQRYF FILE(FACT) FORMAT(FMT1) GRPFLD(NOCLI) MAPFLD((NB %COUNT) (SOMME %SUM(MONTANT)) (DEPUIS %MIN(DATE)))
groupe les enregistrements du fichier FACT (pour facture) par numro de client (NOCLI). Pour chacun de ces clients, NB est le nombre total de facture en cours, SOMME est le montant total de ce qui est d et DEPUIS est la plus petite date.
Le tri
Le paramtre KEYFLD prsente les enregistrements tris sur une ou plusieurs zones.
La jointure
La jointure mise en uvre pour lOpen Query File est beaucoup moins restrictive que celle des fichiers logiques joints. En effet, pour ces derniers seule lgalit des zones mises en concordance est vrifie. Avec le paramtre JFLD, la jointure peut tre effectue sur nimporte quel oprateur de comparaison (gal, suprieur, infrieur...). Par exemple :
OPNQRYF FILE(FICH1 FICH2) FORMAT(FMT1) JFLD(1/Z1
2/Z1 *EQ)
tablit une jointure entre les zones Z1 des fichiers FICH1 et FICH2.
237
Performances
La commande OPNQRYF sappuie sur loptimiseur que nous avons dj dcrit pour SQL. Les mmes remarques sy appliquent donc. Il faut remarquer que les chemins daccs (ou index) existants peuvent tre utiliss si loptimiseur le dcide.
Conclusions
OPNQRYF
ou DDS ? Beaucoup se posent la question !
Les avantages de lOpen Query File sont nombreux : les critres de slection sont totalement dfinis au dernier moment ce qui laisse une grande souplesse aux applications ; certaines de ses fonctions ne sont pas disponibles dans les DDS (groupage, slection sur une variable, fonctions mathmatiques et arithmtiques...). Son principal inconvnient rside dans le fait que les oprations de slection sont effectues au dernier moment, ce qui provoque des consommations de ressources importantes (CPU et disques) et des temps de rponses dissuasifs pour linteractif si le nombre denregistrements traiter est important. Il est alors essentiel daider loptimiseur par la cration de chemins daccs et par lutilisation de requtes adaptes.
Les commandes de copie

La commande CPYF est une puissante fonction de copie de fichier. Elle permet deffectuer une slection des enregistrements copier partir de nombreux critres. Elle facilite, par exemple, la cration de jeux de tests en phase de dveloppement et la cration dun nouvel environnement partir dun environnement dj existant (une nouvelle comptabilit peut ventuellement hriter dune partie du plan comptable dune autre).
Les fichiers
Le fichier (physique ou logique) contenant les donnes dorigine est dfini dans le paramtre FROMFILE et le fichier de destination dans TOFILE. Sil nexiste pas, ce dernier peut tre automatiquement cr si CRTFILE(*YES) est spcifi. Il aura le mme format que le fichier dorigine.
Les membres
238
Si le fichier dorigine possde plusieurs membres la copie peut crer un nombre variable de membres en fonction des valeurs des paramtres FROMMBR et TOMBR.
FROMMBR
dfinit les membres du fichier dorigine qui vont tre copis et TOMBR indique o ils vont tre copis. Par exemple :
CPYF FROMFILE(ORIGINE) TOFILE(DESTINAT) FROMMBR(*ALL) TOMBR(*FIRST) MBROPT(*REPLACE)
copie tous les enregistrements du fichier ORIGINE dans le premier membre du fichier DESTINAT, en crasant les anciennes donnes de ce membre ;
CPYF FROMFILE(ORIGINE) TOFILE(DESTINAT) FROMMBR(*ALL) TOMBR(*FROMMBR) MBROPT(*REPLACE)
conserve la mme structure, au niveau des membres et des donnes, entre les deux fichiers. Les membres dorigines qui ne sont pas prsent dans le fichier de destination seront automatiquement crs. Les membres du fichier de destination qui ne sont pas prsents dans le fichier dorigine ne seront pas touchs. supprime les enregistrements du membre de destination avant dinsrer les nouveaux, MBROPT(*ADD) ajoute les nouveaux enregistrements aux anciens.
MBROPT(*REPLACE)
Impression
La copie peut seffectuer destination dun fichier spoule si TOFILE(*PRINT) est codifi. Le format dimpression peut alors tre sous forme hexadcimale (OUTFMT(*HEX)) ou sous forme de caractres (OUTFMT(*CHAR)). Le fichier dimpression utilis par le systme est QSYSPRT et ltat gnr aura le mme nom. Le paramtre PRINT prcise les caractristiques de ltat rcapitulatif. Le fichier spoule gnr contient soit la liste des enregistrements slectionns (PRINT(*COPIED)) soit celle de ceux qui sont exclus de la copie (PRINT(*EXCLD)).
La slection denregistrements
Les enregistrements copier peuvent tre dfinis selon les critres suivants : en fonction de la position relative de l'enregistrement : de lenregistrement situ la position spcifie dans le paramtre FROMRCD jusqu celui correspondant TORCD ;
239
en fonction de la valeur de cl. La copie est effectue de lenregistrement qui a la valeur de cl associe FROMKEY jusqu celui ayant TOKEY ; la copie affectera un nombre maximal denregistrement spcifi dans NBRRCDS ; seuls les enregistrements contenant certaines valeurs seront copis. Il faut utiliser le paramtre INCCHAR pour tester le contenu dune zone de type Alphanumrique. INCREL sert dfinir une proposition logique laquelle doit satisfaire les zones. Par exemple :
CPYF FROMFILE(ORIGINE) TOFILE(DESTINAT) FROMMBR(*ALL) TOMBR(*FROMMBR) MBROPT(*REPLACE) INCCHAR(ZONE1 2 *CT FRA) INCREL((*IF ZONE2 *GT 50) (*AND ZONE3 *EQ 0)
ne copie que les enregistrements qui ont FRA contenu dans ZONE1, partir de la deuxime position, ZONE2 suprieur 50 et ZONE3 gal 0.
Vrification
Le paramtre FMTOPT permet une vritable copie intelligente lorsque les formats du fichier dorigine et ceux du fichier de destination sont diffrents. Par dfaut, les deux formats doivent tre identiques. La copie est alors trs rapide sans vrification. Sinon, la valeur FMTOPT(*NOCHK) provoque une copie de lenregistrement dorigine dans celui de destination, octet par octet partir de la gauche, sans aucune vrification. Il faut parfaitement matriser le rsultat pour utiliser une telle valeur.
FMTOPT(*MAP)
recherche dans le fichier de destination les zones qui ont le mme nom que celles du fichier dorigine. Cette option est indispensable si une zone a chang de place dans le format ; cette vrification la retrouvera et lui transmettra les donnes de la zone dorigine ayant le mme nom. Si la zone a aussi chang de description, il est possible que la copie se fasse mal. Prenons, par exemple, la valeur 123 qui est contenue dans une zone du fichier dorigine de longueur 3 dont 0. Si la zone de destination fait maintenant 2 dont 0, la copie ne pourra seffectuer normalement et la zone de destination hritera de la valeur par dfaut. Ceci est moins flagrant pour les zones alphanumriques car elles peuvent tre tronques.
Les zones du format de destination qui nont pas dquivalence sont initialises avec leur valeur par dfaut. Lorsque des zones du format dorigine nont pas dquivalence dans le format de destination il faut codifier FMTOPT(*DROP) afin quelles soient ignores par la copie. La valeur *MAP peut tre codifie avec *DROP (figure 7.3).
240
ZONE1 12345
ZONE3 ZONE2 ZONE5 0 ABCDEF 0
CPYF FMTOPT(*MAP *DROP)
ZONE1 12345
ZONE2 ZONE3 ABCDEFGHIJKL 1234567890
ZONE4 98765
Figure 7.3 : le paramtre FMTOPT de la commande CPYF. et ZONE3 peuvent tre copies bien quelles soient inverses dans le fichier de destination car FMTOPT(*MAP) est codifi. ZONE4 est ignore car elle nentre pas dans la composition du format de destination et car FMTOPT(*DROP) est spcifi. Il faut remarquer que le format de ZONE3 ayant chang, la zone de destination ne peut accueillir les donnes dorigine ; elle est donc initialise avec sa valeur par dfaut.
ZONE2
Vers un fichier source

La commande CPYF permet aussi de copier destination dun fichier source. Les paramtres SRCOPT et SRCSEQ dfinissent la numrotation des lignes insres dans le membre source.
Les enregistrements supprims

Les enregistrement du fichier dorigine peuvent tre supprims de la copie si COMPRESS(*YES) est prcis. Cest la valeur par dfaut.
Les diffrentes commandes de copie

Il existe dautres commandes de copie, voici les principales :
CPYFRMDKT CPYFRMTAP CPYSPLF CPYSRCF CPYTODKT CPYTOTAP
copie partir dun fichier disquette ; copie partir dun fichier bande ; copie un fichier spoule destination dun fichier ; copie partir dun fichier source ; copie dun fichier vers un fichier disquette ; copie dun fichier vers un fichier bande.
241
Si les donnes copier sont en provenance, ou destination, dun systme autre que lAS/400, on peut utiliser lune des fonctions suivantes : Client Access/400 (ou PCS/400) pour transfrer des donnes vers, ou depuis, un micro-ordinateur sous DOS, Windows ou OS/2 ; FTP, qui sappuie sur TCP/IP, pour changer des fichiers avec toute plateforme qui supporte ce protocole (en particulier les systmes Unix) ; ODBC, qui permet une application sexcutant sous Microsoft-Windows dtre indpendante de la base de donnes. Lutilisateur peut choisir au dernier moment o il va chercher les donnes. Il slectionne pour cela un pilote ODBC (couramment nomm driver). LOS/400 fournit un pilote pour accder sa base de donnes depuis la V2R3M0, sous forme de trois PTF au dbut, puis totalement intgr Client Access/400 ensuite.
Les commandes de substitution

La substitution de fichier nous permet de leurrer un programme dans le sens ou ce dernier croit travailler avec un fichier alors que le systme lui en renvoie un autre. Cette fonction est utilise principalement dans les cas suivants : lorsquun fichier doit tre remplac par un autre de mme format (nouvelle anne en comptabilit, nouveau stock, nouvelle agence...) sans que lon retouche le programme ; lorsque lon dsire travailler sur un membre particulier ; et dune manire gnrale chaque fois que lon dsire modifier les caractristiques dun fichier. Les commandes de substitution agissent pour le travail en cours seulement et nont donc pas deffet pour le reste du systme. Leur effet est aussi limit dans le temps car les substitutions disparaissent au maximum la fin du travail. Pour modifier un fichier de manire permanente et pour tous les utilisateurs on utilisera une commande de type CHGxx. La commande OVRDBF permet de modifier les caractristiques dun fichier base de donnes (physique ou logique) pour un travail. Voici ses principaux paramtres : FILE permet de donner le nom du fichier substituer ; TOFILE dfinit le nom du fichier qui remplace celui qui est spcifi dans le paramtre FILE.
242
Par exemple :
OVRDBF FILE(FICH95) TOFILE(FICH96)
provoque pour le travail en cours la substitution du fichier FICH95 par FICH96. Aprs cette commande, un programme utilisant FICH95 recevra les donnes de FICH96 condition que ces deux fichiers aient le mme format ; MBR prcise le nom du membre qui est vu. Ainsi :
OVRDBF FILE(STOCK95) TOFILE(*FILE) MBR(HERAULT)
met le membre HERAULT disposition des applications qui utilisent STOCK95. Ce type de substitution est le seul moyen (avec la commande OPNDBF) qui permette de traiter les enregistrements dun membre qui nest pas le premier dans un fichier ; POSITION indique o se place le pointeur denregistrement, autrement dit dfinit le premier enregistrement qui sera lu (le premier, le dernier, celui plac en position N, celui qui a une certaine valeur de cl...) ; SHARE permet le partage de lODP entre plusieurs programmes dun mme travail, ou dun mme groupe dactivation ; OVRSCOPE dfinit la porte de la substitution. Elle peut tre limite : *ACTGRPDFN : au groupe dactivation du programme qui appelle cette commande, *JOB : au travail, *CALLLVL : au niveau dappel en cours. La valeur du niveau dappel peut tre visualise par la commande DSPJOBLOG. Elle correspond aux nombres placs gauche des commandes ; et un ensemble de paramtres dj dfinis pour les commandes CRTPF et CRTLF. La substitution est valable jusqu lmission de la commande DLTOVR ou jusqu la fin du travail. La commande DSPOVR permet de visualiser les substitutions pour le travail en cours.
243
Il existe dautres commandes de substitution. Voici les principales :

OVRPRTF OVRDSPF OVRMSGF OVRSAVF OVRTAPF
substitue un fichier dimpression ; substitue un fichier daffichage ; substitue un fichier de messages ; substitue un fichier de sauvegarde ; substitue un fichier bande.
Ouverture et fermeture contrle des fichiers

Les programmes qui utilisent des fichiers les ouvrent et les ferment automatiquement. Le dveloppeur peut choisir de contrler ces oprations pour des besoins particuliers. Les commandes OPNQRYF et CLOF permettent douvrir et de fermer des fichiers dans un programme. Par exemple :
OPNDBF FILE(FICH1) MBR(HERAULT) ACCPTH(*ARRIVAL)
force louverture du fichier FICH1. Les enregistrement traits seront ceux du membre HERAULT, ils seront vus selon lordre darrive mme si un chemin daccs est dfini pour ce fichier. La commande POSDBF permet de positionner le pointeur denregistrement au dbut ou la fin du membre. Le fichier est ferm par la commande CLOF. Les langages de haut niveau permettent aussi de grer louverture et la fermeture des fichiers. En RPG, il faut codifier UC (User Control) dans la spcification F du fichier puis utiliser les codes opration OPEN et CLOSE. Mais il sagit l uniquement de dcider quand un fichier doit tre ouvert et non pas comment il doit ltre. La diffrence avec la commande OPNDBF est donc fondamentale.
Les rfrences croises

LOS/400 ne donne aucun outil pour grer les rfrences croises. Il est, par exemple, assez difficile de connatre tous les programmes qui utilisent un fichier ou tous les fichiers qui rfrencent une zone du dictionnaire. Et cela est pourtant indispensable quand on doit faire voluer un systme dinformation. Quelques commandes renvoient la description dobjets (programmes et fichiers). Elles permettent dcrire des programmes en langage de contrle automatisant le traitement de certaines rfrences croises. Les API apportent beaucoup plus de
244
puissance et de rapidit de traitement. Elles demandent, par contre, de matriser quelques techniques de dveloppement rputes complexes.

Parmi les principales commandes qui nous permettent dtablir des rfrences croises nous pouvons remarquer : DSPPGMREF qui liste les diffrents objets utiliss par un programme ; PRTCMDUSG qui gnre un fichier spoule indiquant quels sont les programmes, en langage de contrle, utilisant une ou plusieurs commandes ; DSPDBR qui prcise les relations dun fichier (par exemple, tous les fichiers logiques qui pointent sur un fichier physique) ; DSPFD qui donne des informations sur un fichier ; DSPFFD qui liste les zones contenues dans un fichier et quelques informations sur le fichier. Ces commandes ne permettent pas la cration dapplications vraiment complexes, cest alors que les API doivent intervenir.
Les API et la base de donnes

Une srie dAPI sur la base de donnes permettent dextraire trs rapidement des informations sur les fichiers. Nous ne rentrerons pas dans les principes de programmation lis aux API, il faudrait un tome supplmentaire, mais un exemple complet est prsent en annexe C. Pour un fichier, il liste les membres qui le composent et propose des informations complmentaires (taille du chemin daccs, nombre denregistrements...). Pour des raisons de concision, il est relativement simple et peut (et doit) tre enrichi. Voici les principales API lies la base de donnes :
QUSLMBR QDBLDBR QUSLFLD QUSLRCD QUSMBRD
liste les membres dun fichier ; liste les relations dun fichier (comparable la commande DSPDBR) ; liste les zones dun format ; liste les formats dun fichier ; extrait des informations sur un membre.
245
On peut ajouter cette liste diverses API qui sont indpendantes de la base de donnes mais qui peuvent savrer utiles pour le traitement de rfrences croises : QCLRPGMI, qui extrait des informations sur un programme, notamment sil contient des requtes SQL ; les API de scurit qui permettent de connatre les droits et les interdictions partir des objets ou des profils utilisateur. Enfin, il faut signaler que les API sur les User Index (objet de type *USRIDX) nous permettent des traitements rapides sur les donnes tels que les tris et les recherches par index.

CLODBF CPYF CPYFRMQRYF CPYSPLF DLTOVR DSPDBR DSPFD DSPFFD DSPPGM DSPPGMREF OPNDBF OPNQRYF OVRDBF OVRDSPF OVRMSGF OVRPRTF PRTCMDUSG
ferme un fichier base de donnes ; copie partir dun fichier base de donnes ; copie partir dun Open Query File ; copie partir dun fichier spoule ; arrte une substitution ; affiche les relations dun fichier ; affiche la description dun fichier ; affiche la description des zones dun fichier ; affiche la description dun programme; affiche les objets utiliss par un programme ; ouvre un fichier base de donnes ; ouvre un Open Query File ; substitue un fichier base de donnes ; substitue un fichier daffichage ; substitue un fichier de messages ; substitue un fichier dimpression ; affiche la liste des programmes qui utilisent une commande.

CMDCPY, CMDOPN, CMDOVR, CMDCPY.
246
GESTION DE LA BASE DE DONNEES.......................................................................231 LA COMMANDE OPNQRYF....................................................................................................231 Principes ........................................................................................................................232 Les principaux paramtres.............................................................................................235 LES COMMANDES DE COPIE .................................................................................................238 LES COMMANDES DE SUBSTITUTION ....................................................................................242 OUVERTURE ET FERMETURE CONTROLEE DES FICHIERS ......................................................244 LES REFERENCES CROISEES .................................................................................................244 Les principales commandes ...........................................................................................245 Les API et la base de donnes........................................................................................245 LES PRINCIPALES COMMANDES ...........................................................................................246 LES PRINCIPAUX MENUS ......................................................................................................246
A
API 245
GROUP BY
G
237
C
chemin daccs 245 Client Access/400 242 CLOF 233; 244 CLOSE 244 CPYF 238 Impression 239 INCCHAR 240 INCREL 240
J
JFLD
D
DDS 238 DLTOVR 233; 243 DSPDBR 245 DSPFD 245 DSPFFD 245 DSPJOBLOG 243 DSPOVR 243 DSPPGMREF 245
237 jointure 237
M
236 239 membre 238
MAPFLD MBROPT
O F
ODBC 242 ODP 233 OPEN 244 OPNDBF 244 OPNQRYF 231; 244 OVRDBF 233; 242
fichier source 241 FMTOPT 240 FROMFILE 238 FROMKEY 239 FROMMBR 239 FROMRCD 239 FTP 242
P
PCS/400 242 POSDBF 244
247
PRINT
239 245 TCP/IP 242 TOFILE 238 TOKEY 239 TOMBR 239 TORCD 239 tri 237
PRTCMDUSG
T Q
QRYSLT
QSYSPRT
235 239
S
scurit 246 SRCOPT 241 SRCSEQ 241 User Index 246
232
Chapitre 8
Les bases de donnes distantes
Pour concrtiser son ouverture, lAS/400 doit permettre laccs aux informations places dans une base de donnes rpartie. LOS/400 met deux fonctions notre disposition pour travailler dans un tel environnement : DDM et DRDA. Laspect communication nest pas abord dans cet ouvrage car il sort du domaine de la base de donnes. Il devrait tre trait par Rmi Borrelly, dans un livre sur lAS/400 et les communications, paratre aux ditions Eyrolles.
Les fichiers DDM

DDM (Distributed Data Management) est une architecture qui permet lchange de donnes entre systmes du monde IBM. Il est disponible sur les plates-formes IBM/36 et IBM/38, sous les systmes CICS et OS/2 (avec quelques restrictions) et se trouve totalement intgr lOS/400. Il permet un utilisateur daccder, de manire transparente, des donnes sans savoir o elles sont stockes (en local, sur un autre AS/400 ou sur une autre plateforme). DDM sappuie sur deux types de systmes : le systme source qui excute le programme qui demande les donnes et le systme cible qui possde ces donnes. LAS/400 peut tre lun ou lautre.
248
Un fichier DDM plac sur lAS/400 source contient toutes les informations pour accder un fichier distant (identification du systme dans le rseau, nom du fichier...). Il est cr par la commande CRTDDMF, sans codification de DDS. En effet, ce type de fichier ne possde aucun enregistrement, donc aucun format. Les seuls lments prciser lors de sa cration concernent laccs au fichier loign et les paramtres de la commande de cration suffisent. Le programme source ne voit que le fichier DDM, il ne connat pas le fichier distant (figure 8.1). Cela est important car, lors de la compilation, le programme doit rcuprer la description du format du fichier qui contient les donnes. Pour se faire, il existe deux manires de procder : si la communication nest pas tablie avec le systme distant lors de la compilation, il faut crer un fichier local de mme format que le fichier loign et citer son nom dans le programme. Il suffira, lors de lexcution, de substituer le fichier local par le fichier DDM grce la commande OVRDBF. Cette mthode permet de tester le programme, sans mettre en uvre les communications, en plaant des donnes dans le fichier local ; si lenvironnement est en place lors de la compilation (fichier DDM cr et communication tablie), le format du fichier distant est automatiquement ramen dans le programme. Dans ce cas, cest le nom du fichier DDM qui doit tre spcifi dans le programme.
PGM1 *PGM
DDM1 *FILE
COMMUNICATIONS
FICH1 *FILE
CRTDDMF DDM1 AS/400 LOCAL SYSTEME DISTANT
Figure 8.1 : utilisation dun fichier DDM.
8 - Les bases de donnes distantes
249
Le fichier distant peut tre un fichier qui contient les donnes ou un fichier logique (si le systme cible est un autre AS/400 ou un IBM/38). Les oprations que lon peut effectuer sur ce fichier, travers le fichier DDM, sont : la gestion des donnes (lecture, criture, mise jour, insertion) partir des ordres spcifique au langage (WRITE, READ, UPDAT en RPG, par exemple) ; louverture et la fermeture ; la copie des donnes laide de la commande CPYF ( partir, ou vers, le systme cible) ; la gestion des membres (cration, destruction, effacement des enregistrements) si le systme cible le supporte (AS/400 et IBM/38) ; le verrouillage (ALCOBJ) et la libration (DLCOBJ). Le fichier DDM et le fichiers distants sont concerns ; laffichage dinformations par les commandes DSPFD et DSPFFD ; et, dune manire gnrale, tout ce qui concerne la gestion des fichiers : la destruction (DLTF), la cration (CRTPF, CRTSRCPF et ventuellement CRTLF), la modification (CHGPF, CHGLF)... Le support est donc complet et permet, vraiment, de travailler avec un fichier distant comme sil tait local. Un fichier DDM peut aussi tre utilis pour lancer une commande sur le systme cible. Il faut, pour cela, utiliser la commande SBMRMTCMD. Par exemple :
SBMRMTCMD CMD('CRTDTAARA DTAARA(BIB1/DTA1) TYPE(*CHAR) LEN(100) TEXT(''POUR COMPTABILITE'')') DDMFILE(LYON)
cre, sur le systme cible dfini par le fichier DDM LYON, la data area DTA1 dans la bibliothque BIB1. Le fichier DDM avait t cr auparavant par la commande :
CRTDDMF FILE(LYON) RMTFILE(DB400/FICH1) RMTLOCNAME(ASLYON)
Quelques restrictions, souvent logiques, sont noter. Voici les principales : les commandes provoquant un affichage ne sont pas utilisables distance (il faut imaginer que le travail sur le systme cible est comparable un batch) ;
250
les fichiers spoules sont, en standard, gnrs sur le systme cible. A partir de la V3R1M0 de lOS/400, il est ventuellement possible de les redescendre automatiquement vers le systme source ; les commandes de substitution sont interdites sur le systme cible. Enfin, les fichiers DDM peuvent, aussi, tre utiliss pour accder des dossiers de lAS/400 partir dun systme distant.
DRDA
DRDA (Distributed Relational Database Architecture) est une architecture qui permet dobtenir une base de donnes distribue entre diffrents systmes du monde SAA (qui peut tre dfini comme tant le monde des ordinateurs de gestion IBM). Elle sappuie sur le langage SQL et permet un utilisateur de grer, de manire transparente, des informations qui proviennent des bases de donnes suivantes : DB2/400 pour lAS/400 ; DB2 sous MVS ; SQL/DS sous VM ; DB2/6000 pour les Risc/6000 sous AIX (lUnix IBM) ; DB2/2 sous OS/2 ; et dautres SGBD qui pourraient rejoindre cette liste. DRDA sappuie sur les fonctions de communication de DDM, mais cela est pratiquement transparent pour lutilisateur. Pour crer des programmes DRDA, il faut avoir le produit SQL/400 sur le systme de dveloppement, car ce langage est la base de la gestion des donnes dans cet environnement. Mais il nest pas indispensable si lAS/400 est seulement source des donnes. Si la base de donnes distante a t dfinie au niveau du systme (par la commande WRKRDBDIRE), lordre SQL CONNECT suffit se positionner dessus. Toute opration sur les donnes qui suivra seffectuera sur cette base jusquau CONNECT suivant, qui dportera sur une autre base. La gestion des donnes distantes est donc extrmement simple.
251
Nous avons dj signal, au chapitre 7, que la stratgie daccs aux donnes tait dfinie lors de la cration dun programme contenant des requtes SQL. Lorsquun tel programme se connecte une base de donnes distante, il faut concevoir cette stratgie sur la machine loigne. Les informations correspondantes sont alors places dans des objets de type *SQLPKG. Ces structures, couramment nommes SQL package, sont donc places sur le systme qui hberge les donnes et correspondent la stratgie daccs pour un programme distant. Pour chaque programme, il doit y avoir un SQL package par base de donnes loigne. Mais, lors de la compilation, on ne peut citer quun seul nom de base de donnes. Les autres packages sont donc crer par la suite, laide de la commande CRTSQLPKG. Les objets de type *SQLPKG peuvent tre grs par des commandes de lOS/400 comme les autres objets. Ils peuvent tre sauvegards, restaurs et mme envoys vers un autre systme condition quils restent dans la mme bibliothque. Pour dtruire un package devenu inutile, on peut utiliser la commande DLTSQLPKG ou lordre SQL DROP PACKAGE. Le systme place une sorte didentificateur de format dans le programme, afin de sassurer que le package utilis est bien le bon.
Conclusions
Les deux fonctions que nous venons de dcrire rapidement assurent que lAS/400 peut totalement sintgrer une base de donnes distribue sur plusieurs systme. Dans ces deux cas, la mise en place est relativement simple et, surtout, reste totalement transparente pour lutilisateur (aux temps de rponses prs !). Il faudrait rajouter les commandes SNDNETF et RCVNETF qui, dans le cadre de SNADS, permettent denvoyer et de recevoir un fichier sur un systme distant. Il sagit l dune base de donnes distribue entre des systmes rpondant SAA, donc essentiellement IBM. La vritable ouverture passe par le support dautres standards. Cest aujourdhui le cas car lAS/400 peut tre totalement intgr des rseaux de type TCP/IP et OSI. Pour TCP/IP, nous avons dj le support de FTP, protocole de transfert de fichiers entre plates-formes htrognes et de NFS, qui rend lAS/400 serveur de fichiers et de documents ( laide du produit File Server Support/400). Lintgration, promise
252
par IBM, de lAS/400 dans le rseau Internet sera un lment dterminant dans le processus douverture. Chaque AS/400 pourra ainsi devenir un serveur de donnes lchelle plantaire, dpassant largement le cadre des ordinateurs IBM.
253

ADDRDBDIRE CHGRDBDIRE CRTDDMF CRTSQLCBL CRTSQLPKG CRTSQLRPG DLTSQLPKG DSPRDBDIRE RCVNETF SBMRMTCMD SNDNETF SNDNETSPLF WRKRDBDIRE
ajouter une entre au rpertoire de base de donnes ; modifier une entre du rpertoire de base de donnes ; crer un fichier DDM ; crer un programme Cobol contenant des requtes SQL ; crer un SQL package ; crer un programme RPG contenant des requtes SQL ; dtruire un SQL package ; afficher les entres du rpertoire de base de donnes ; recevoir un fichier ; soumettre une commande un systme distant via DDM ; envoyer un fichier ; envoyer un fichier spoule ; grer les entres du rpertoire de base de donnes.

CMDSND, CMDTCP, CMDRCV, CMDRDB.
254
LES BASES DE DONNEES DISTANTES.....................................................................247 LES FICHIERS DDM.............................................................................................................247 DRDA ................................................................................................................................250 CONCLUSIONS .....................................................................................................................251 LES PRINCIPALES COMMANDES ...........................................................................................253 LES PRINCIPAUX MENUS ......................................................................................................253
Internet 251
A
ALCOBJ
249 MVS 250
M N
NFS 251
C
249 CHGPF 249 CICS 247 CONNECT 250 CPYF 249 CRTDDMF 248 CRTLF 249 CRTPF 249 CRTSQLPKG 251 CRTSRCPF 249
CHGLF
O
OS/2 247 OSI 251
P
package 251
D
DB2 250 DB2/2 250 DB2/400 250 DB2/6000 250 DDM 247; 250 DDS 248 DLCOBJ 249 DLTF 249 DLTSQLPKG 251 DRDA 250 DROP PACKAGE 251
R
RCVNETF READ
251
249
S
SBMRMTCMD
249
SGBD 250 SNDNETF 251 SQL/DS 250
F
FTP 251
T
TCP/IP 251
I
UPDAT
U
249
IBM/36 247 IBM/38 247
248
WRITE
249 250
WRKRDBDIRE
Glossaire
Ce glossaire reprend les nologismes utiliss, dfinit les sigles et abrviations, et dcrit les termes techniques. API (Application Program Interface) Primitive insrer dans des programmes (RPG, Cobol, langage de contrle...) pour disposer de fonctionnalits volues. Certaines API sont livres avec des produits tels que PCS/400 ou Office Vision/400, d'autres sont disponibles en standard et permettent d'utiliser les donnes et les fonctions avances du systme. Architecture Unifie d'Applications (Systems Application Architecture ou SAA) Stratgie dfinie par IBM en 1987 pour augmenter la productivit des programmeurs et des utilisateurs, en normalisant 3 domaines: l'interface utilisateur (voir CUA) ; les communications (voir CCS) ; la programmation (voir CPI).
ASP (Auxiliary Storage Pools) Un pool de mmoire secondaire est une portion (ou la totalit) de la mmoire secondaire. L'ASP systme est la partie gre directement par le systme ; il peut occuper tous les disques et est obligatoire. Un ASP utilisateur est une partie facultative de la mmoire secondaire o le systme n'est pas libre d'agir. Il ne placera des objets que sur lordre de lutilisateur. C'est un moyen d'isoler les objets lis la journalisation et les fichiers de sauvegarde, des donnes d'origine.
268
Base de donnes Ensemble des objets et des programmes qui permettent la gestion des donnes (souvent qualifi de SGBD pour Systme de Gestion de Base de Donnes). L'AS/400 est livr en standard avec un systme de gestion de base de donnes relationnelle : DB2/400. C'est le seul moyen de grer les donnes sur ce systme. Batch Travail se droulant en tche de fond, sans interaction avec un utilisateur. Ce type de travail est oppos l'interactif. Bibliothque Objet de type *LIB qui permet de classer les objets. Une bibliothque n'est pas un espace rserv sur le disque mais elle est constitue d'un index qui pointe sur des objets rpartis n'importe o sur le disque. Elle n'a donc pas de taille limite. Toute bibliothque est rattache QSYS. CCS (Common Communications Support) Composant de l'Architecture Unifie d'Applications qui dfinit l'architecture et les protocoles permettant la communication entre les diffrentes plates-formes SAA. Chemin d'accs Composant des fichiers physiques et logiques comparable un index qui permet un programme de voir les enregistrements d'une certaine manire. Il contient la cl des enregistrements correspondant aux critres de slection, et leur adresse. CIR Voir contrainte dintgrit rfrentielle. CL
1 sens : les membres sources de type CL contiennent des instructions qui seront interprtes lors de la soumission d'un flot de travaux ; 2 sens : (Control Language) les programmes compils contenant des commandes du langage de contrle sont souvent appels Programmes CL . Les membres sources de ces programmes sont de type CLP. Pour viter toute confusion avec les flots de travaux (voir le premier sens), nous avons prfr la terminologie CLP (voir CLP). CLP Type de membre source. Ce membre, contenant des commandes du langage de contrle, sera compil pour donner un programme (objet de type *PGM). Dans cet ouvrage, ces programmes seront nomms Programmes CLP .
e
er
Glossaire
269
Commit Voir validation. Contrainte dintgrit rfrentielle Fonction de DB2/400 permettant dassurer lintgrit de la base de donnes. Une (ou plusieurs) zone(s) dun fichier dpendant est associe une (ou plusieurs) zone(s) dun fichier parent. Chaque zone du fichier dpendant, ainsi dfinie, ne pourra recevoir quune valeur existant dj dans la zone du fichier parent qui lui est associe. Contrle de validation Processus associ la journalisation qui permet de s'assurer qu'une transaction s'est bien termine. Toute transaction incomplte sera annule afin de conserver l'intgrit de la base de donnes. CPI (Common Programming Interface) Composant de l'Architecture Unifie d'Applications (SAA) dfinissant les langages de programmation et les outils de dveloppement. Cette normalisation assure une portabilit optimale des programmes entre les diffrentes plates-formes SAA et une meilleure productivit des programmeurs. CUA (Common User Acces) Composant de l'Architecture Unifie d'Applications (SAA) dfinissant les interactions avec l'utilisateur. L'utilisation des touches de fonction et l'aspect des crans sont normaliss. DDS (Data Description Specification) Langage de dfinition des objets de type fichier. Les DDS sont composes de motscls et doivent tre codifies en respectant un colonage rigoureux. Un membre source compos de DDS sera compil par une commande CRTxx pour donner un objet de type fichier (*FILE). Ce dernier peut tre un fichier d'affichage (attribut DSPF), un fichier d'impression (attribut PRTF) ou un fichier base de donnes (attribut PF pour les fichiers physiques ou LF pour les fichiers logiques). Les autres types de fichiers ne seront pas vus dans cet ouvrage. Certains utilisent le terme de SDD pour Spcification de Description de Donnes, mais, pour viter toute confusion au niveau de la documentation, nous avons gard le terme anglo-saxon comme il est de coutume pour l'AS/400. DDM (Distributed Data Management) Fonction de lOS/400 permettant une application daccder des donnes situes sur un systme distant (AS/400, IBM/36 et IBM/38 essentiellement).
270
Dclencheur (trigger) Fonction de DB2/400 associant un programme (dit dclencheur) un vnement, pour un fichier physique. Si cet vnement se produit, le programme dclencheur est lanc.
Glossaire
271
DFU (Data File Utility) Utilitaire de la base de donnes utilis pour la maintenance des fichiers. Document Un document est un lment bureautique produit par Office Vision/400 ou un fichier provenant du monde de la micro-informatique grce PCS/400 ou Client Access/400. L'AS/400 gre les documents mais ne sait pas ce qu'il y a l'intrieur. Dossier Structure qui regroupe des documents et des dossiers. DRDA (Distributed Relational Database Architecture) Architecture de base de donnes rpartie dIBM. DTAARA (data area) Une zone de donnes est un objet de type *DTAARA. Elle contient une seule information dont le type et la longueur sont dfinis lors de sa cration (voir LDA). DUMP Extraction du contenu dune structure. Le dump dun objet est une image hxadcimale de son contenu (partie descriptive et donnes) obtenue par la commande DMPOBJ. Pour un document, il faut utiliser DMPDLO. La commande DMPJOB renvoie des informations sur un travail. Les informations gnres par ces commandes sont places dans un fichier spoule nomm QPSRVDMP. Fichier de sauvegarde Objet de type *FILE, attribut SAVF, destin recevoir une sauvegarde. Fichier logique Structure de la base de donnes permettant au programme de voir les enregistrements d'un (ou de plusieurs) fichier(s) physique(s) d'une certaine manire. Cette vue comprend des tris, des slections d'enregistrements sur certains critres, des projections de zones et des jointures (au sens relationnel). Un fichier logique est codifi partir de DDS, il est de type *FILE, attribut LF. Il ne contient pas d'enregistrements, mais seulement la manire de voir ces enregistrements. Fichier physique Structure de la base de donnes contenant les enregistrements. Un fichier physique est codifi partir de DDS, il est de type *FILE, attribut PF. Fichier source Objet de type *FILE, attribut SRC-PF, dont les membres contiennent les sources de programmes ou les DDS de fichiers.
272
Fichier spoule (spool file) Un fichier spoule reprsente un tat imprimer. Ce nest pas rellement un fichier, ni mme un objet de lOS/400. Il est rattach une file dattente en sortie (OUTQ). FTP Protocole de transfert de fichiers sous TCP/IP. Giga-octet Milliard de caractres. Guide oprateur Voir invite. IFS (Integrated File System) Fonction de lOS/400 ( partir de la V3R1M0) qui assure le support des systmes de fichiers de type Unix, Lan serveur, micro-informatique (MS/DOS, OS/2), en cohabitation avec la gestion native des objets et des documents dans les dossiers. Indicateur Variable de type logique permettant d'changer une information lmentaire dans les programmes. Nous avons 99 indicateurs notre disposition (appels 01 99), d'autres ont une signification particulire pour le systme. Un indicateur est soit gal 1, auquel cas il est en-fonction ou vrai, soit gal 0, il est alors hors-fonction ou faux. Interactif Travail ncessitant une interaction avec un utilisateur par l'intermdiaire d'un poste de travail. Invalidation (rollback) Opration du contrle de validation consistant annuler lensemble des oprations dune transaction. Invite (prompt) Fonction d'assistance permettant de saisir les valeurs des diffrents paramtres d'une commande. Pour y accder, il suffit de taper le nom de la commande sur la ligne "Option commande" et d'appuyer sur F4. IPL (Initial Program Load)
Glossaire
273
Phase de dmarrage qui charge le systme en mmoire partir d'un support magntique, qui vrifie le matriel et qui met en place les fonctions qui vont permettre aux travaux de s'excuter.
274
JOBD Une description de travail est un objet de type *JOBD. Elle dcrit l'environnement d'excution d'un travail. JOBQ Une file d'attente de travaux est un objet de type *JOBQ. Elle accueille les travaux qui ont t soumis, avant qu'ils ne s'excutent dans un sous-systme. Journal Objet de type *JRN qui, avec les rcepteurs de journaux, recueille toutes les modifications qui ont affect les objets qui lui sont associs. Journalisation Mise en place de journaux qui vont recenser toutes les modifications qui ont lieu sur les objets journaliss. LDA (Local Data Area) Zone de donnes (DTAARA) particulire qui est cre automatiquement avec chaque nouveau travail. Elle n'est accessible qu' partir des diffrents programmes de ce travail, sous le nom de *LDA. Elle est initialise avec un type Alphanumrique dune longueur de 1024 caractres. LF (Logical File) Voir fichier logique. Mga-octet Million de caractres. Membre Les membres sont des composants des fichiers physiques et logiques. Ils correspondent un ensemble de donnes. Par dfaut, un fichier a un membre qui porte le mme nom. Membre source Membre d'un fichier source contenant les instructions d'un programme ou les DDS d'un fichier. Mmoire secondaire Ensemble des disques durs. Sa taille se mesure en giga-octet (milliard de caractres). MSGQ
Glossaire
275
Une file d'attente de messages est un objet de type *MSGQ. Elle accueille les messages destination d'un utilisateur, d'un objet ou d'un programme. Objet La notion d'objet dsigne les structures sur lesquelles l'OS/400 peut effectuer des oprations. Ces objets ont une partie descriptive et une partie qui contient les donnes propres cet objet. Le type de l'objet dfinit le format de ses donnes. Toutes les notions abordes ici se rfrent au concept d'objet. Il existe aussi un autre mode de gestion de l'information sur l'AS/400 qui n'utilise pas la notion d'objet, mais la notion de documents dans des dossiers. Objet de notification Objet de type *MSGQ, *FILE ou *DTAARA associ au contrle de validation, qui permet de connatre la dernire transaction valide. Octet Srie de huit informations lmentaires (bits) permettant de coder un caractre. Office Vision/400 Programme sous licence assurant les tches de bureautique de lAS/400. Optimiseur Composante de la base de donnes charge de dfinir la stratgie daccs pour SQL, pour la commande OPNQRYF, pour Client Access/400... OS/400 (Operating System/400) Systme d'exploitation de l'AS/400. OUTQ Les files d'attente en sortie sont des objets de type *OUTQ. Elles accueillent les tats en attente d'impression. Package Voir SQL package. Paramtre lment d'une commande qui prcise le type du traitement effectuer (sur qui, comment...). PCS/400 Logiciel sous licence permettant un micro-ordinateur de type PC/PS de se connecter de manire intelligente un AS/400. Il assure les fonctions de terminal,
276
d'change de donnes, de partage des ressources (imprimantes, disques...). A partir de la version 3 de lOS/400, il est nomm Client Access/400. PDM (Programming Development Manager) Environnement de dveloppement utilisable pour tous les langages de lAS/400. PF (Physical File) Voir Fichier physique. PGMQ C'est une file d'attente de messages qui reoit les messages destins un programme. Elle constitue une partie de la file d'attente de messages associe au travail. Profil utilisateur Objet de type *USRPRF qui regroupe les informations propres chaque utilisateur. On y trouve son nom, son mot de passe (non visualisable), des donnes lies la scurit, et enfin la dfinition de son environnement de travail. C'est un des composants essentiels de la scurit, et de l'organisation des travaux sur l'AS/400. PTF (Program Temporary Fix) Correction logicielle ou nouvelle fonctionnalit apportes un problme particulier. QGPL (General-Purpose Library) Bibliothque contenant certains objets lis au systme et les objets crs par des utilisateurs sans qu'une bibliothque puisse tre attribue (objets non qualifis et absence de bibliothque courante). QPJOBLOG Fichier spoule correspondant l'historique d'un travail. QSYS Bibliothque fondamentale qui contient la majeure partie de l'OS/400, les objets lis la scurit et les bibliothques.
QSYSOPR
File d'attente de messages associe l'oprateur systme. C'est un objet standard. Query/400 Utilitaire permettant dinterroger simplement la base de donnes. Restauration (recovery) Opration qui permet de ramener en mmoire secondaire le contenu d'une sauvegarde.
Glossaire
277
RLU (Report Layout Utility) Utilitaire d'aide la gnration de fichiers d'impression. Rollback Voir invalidation. RPG (Report Program Generator) Langage de programmation de la mini-informatique IBM, anciennement appel GAP (Gnrateur Automatique de Programme). Le RPG/400 tait le langage de programmation phare sur l'AS/400. Il cohabite maintenant avec le RPG IV, compilateur ILE, apparu avec la V3R1M0 de lOS/400. Il existe aussi sur d'autres plates-formes. SAA (Systems Application Architecture) Voir Architecture Unifie d'Applications. Sauvegarde (backup) Opration qui consiste dupliquer des informations sur un support diffrent dans le but de pouvoir les rcuprer si les donnes d'origine taient perdues ou dtruites. SAVF (save file) Voir fichier de sauvegarde. SDA (Screen Design Aid) Outils de dveloppement et de test des fichiers d'affichage et des menus. SDD (Spcification de Description de Donnes) Voir DDS. SEU (Source Entry Utility) diteur de source intgr l'environnement de dveloppement. SMAPP Fonction standard de lOS/400 assurant lintgrit des chemin d'accs pour raccourcir le temps des IPL aprs arrt anormal (depuis la V3R1M0 de lOS/400). SNADS (Systems Application Architecture Distribution Services) Fonction de lOS/400 permettant la distribution de fichiers, dimpressions, du courrier et de messages entre systmes distants appartenant SAA.
278
SQL (Structured Query Language) Langage de gestion et de manipulation des donnes couramment utilis avec les bases de donnes relationnelles. SQL package Objet de type *SQLPKG dfinissant la stratgie daccs aux donnes dun programme distant, contenant des requtes SQL.
Glossaire
279
TCP/IP Protocole de communication couramment utilis dans les environnements non-SAA (Unix, par exemple). Le parc install est considrable. Ce protocole est notamment la base des changes lintrieur dInternet. Transaction Ensemble doprations ininterruptibles sur lequel sapplique la loi du tout ou rien. Ou toutes les oprations seffectuent normalement ou aucune de ces oprations ne doit tre ralise. Trigger Voir dclencheur. Type d'objet Le type d'un objet dfinit la nature de l'objet : programme, fichier... User Index Objet de type *USRIDX permettant de grer des donnes la manire dun fichier. Les accs peuvent seffectuer en squentiel ou sur cl. Ils sont utilisables seulement avec les API ou avec le langage C. User Space Objet de type *USRSPC qui est utilis par les API de liste pour renvoyer des informations en nombre variable. Ces objet doivent tre grs avec des API. Ils peuvent tre compars des Data Area de grande taille (jusqu 16 Mga octets). Valeurs systme Ensemble de paramtres propres au systme qui permettent de configurer les AS/400 en fonction des besoins de chaque entreprise. Ces valeurs systme vont de la dfinition de l'heure, la dtermination du niveau de scurit, en passant par l'attribution d'une imprimante par dfaut. A ce jour, il existe une centaine de ces valeurs. Validation (commit) Opration du contrle de validation consistant valider les diffrentes oprations dune transaction.
280
GLOSSAIRE
267
A
API 267 ASP 267 LDA 272
L M
membre 272 membre source 272
B
bibliothque 268
C
chemin d'accs 268 contrle de validation 269
O
objet de notification 273 Office Vision/400 273 OUTQ 273
D
DDM 269 DDS 269 DFU 270 DMPDLO 270 DMPJOB 270 DMPOBJ 270 document 270 dossier 270 DRDA 270 DUMP 270 PCS/400 273 PGMQ 274 PTF 274
Q
QGPL 274
QPJOBLOG 274 Qsys 274 Query 274
F
fichier source 270 FTP 271 restauration 274
R S
SAA 267; 275 sauvegarde 275 SDA 275 SGBD 268 SNADS 275 SQL 275 SQL package 275
I
IFS 271 indicateur 271 Internet 276 IPL 271
J
272 272 journal 272
JOBD JOBQ
268
T
TCP/IP 276 trigger 269; 276 user Space 276
Conclusions
Les avantages de DB2/400 sont nombreux, nous avons pu en juger tout au long de cet ouvrage. Retenons sa totale intgration lOS/400, son support de SQL et son ouverture. Avec larrive de la V3R1M0, la base de donnes de lAS/400 est devenue mature. Le support des contraintes dintgrit rfrentielle et des dclencheurs, qui lui faisait cruellement dfaut, est maintenant ralit. Ces fonctions, longues arriver, sont trs bien intgres au systme et devraient connatre un rel succs. On peut seulement reprocher DB2/400 limpossibilit de modifier dynamiquement la structure dun fichier sans avoir le recrer mais cela devrait arriver avec la prochaine version, et son manque doutils pour grer les rfrences croises. Mais les diteurs de logiciels ont su pallier cette lacune en proposant des produits adapts. DB2/400 peut tre totalement intgr des bases de donnes rparties et htrognes appartenant au monde IBM, videmment, mais aussi des rseaux TCP/IP et OSI. DB2/400 est un des atouts majeurs de lOS/400. Gageons quIBM mettra tout en uvre pour que cette base de donnes reste un des fleurons des SGBD relationnels. Pour lheure, lAS/400 affiche une sant florissante (plus de
254
300 000 units vendues dans le monde). Il souvre aux nouvelles technologies (multimdia, CD-Rom, interface graphique, processeur Risc) et supporte pratiquement tous les protocoles de communication. DB2/400 a donc un bel avenir devant lui. Il pourrait notamment profiter de lexplosion du rseau plantaire, dans lequel il devrait totalement sintgrer en devenant serveur Internet.
255
CONCLUSIONS...............................................................................................................253
D
DB2/400 253 OSI 253
O T
TCP/IP 253
I
Internet 254
M
multimdia 254
Annexe A
Feuille de spcification A
La page suivante prsente un exemple de feuille de spcification A.
256
Annexe A
257
FEUILLE DE SPECIFICATION A................................................................................255
16/01/2007
Annexe B
Les types de postes de la journalisation
Voici les principaux codes et types codifis dans les postes des journaux. Code A : ces postes sont en relation avec la comptabilit des travaux. Ils proviennent du journal QACGJRN de QSYS. Code A A A Type DP JB SP Description Impression directe Information sur les travaux Information sur les impressions
Code C : ces postes concernent le contrle de validation. Code C C C C C Type BC CM EC RB SC Description Dbut du contrle de validation (STRCMTCTL) Validation (COMMIT) Fin du contrle de validation (ENDCMTCTL) Annulation (ROLLBACK) Dbut de cycle de validation
258
Code F : ces postes contiennent des informations sur les fichiers. Code F F F F F F F F F F F F F F F F F F F F F Type AY CL CR EJ EP IU IZ JM JP MD MF MM MN MR MS OP RC RG SA SR SS Description Recouvrement avant (APYJRNCHG) Membre ferm Membre effac (CLRPFM) Arrt de la journalisation (ENDJRNPF) Arrt de la journalisation des chemin daccs (ENDJRNAP) Membre en cours dutilisation lors darrt anormal du systme Initialisation dun membre (INZPFM) Dbut de journalisation dun fichier physique (STRJRNPF) Dbut de journalisation dun chemin daccs (STRJRNAP) Membre dtruit (DLTF ou RMVM) Membre sauvegard avec libration de la mmoire Fichier physique (et membre) dplac (MOVOBJ) Fichier physique ou membre renomm (RNMM ou RNMOBJ) Membre restaur (RSTOBJ ou RSTLIB) Membre sauvegard (SAVLIB, SAVOBJ, SAVCHGOBJ) Membre ouvert Recouvrement arrire pour un membre (RMVJRNCHG) Fichier rorganis (RGZPFM) Dbut dapplication dun recouvrement avant (APYJRNCHG) Dbut dapplication dun recouvrement arrire (RMVJRNCHG) Dbut de la sauvegarde en mise jour
Code J : ces postes sont lis la journalisation. Code J J J J J J Type IA IN NR PR RR RS Description IPL prs arrt anormal IPL aprs arrt normal Nom du rcepteur suivant Nom du rcepteur prcdent Restauration dun rcepteur de journal Sauvegarde dun rcepteur de journal
Code R : ces entres correspondent des oprations sur les enregistrements. Code R R R Type DL DR PT Description Enregistrement dtruit Enregistrement dtruit par un ROLLBACK Enregistrement ajout
Annexe B - Les types de postes de la journalisation
259
UP
Image aprs dun enregistrement mis jour
260
Code S : ces postes sont lis SNADS. Code S S S Type AL ER LG Description Alerte pour un point focal Une erreur a t dtect par SNADS Une opration denvoi ou de rception sest bien termine
Code T : les informations contenues dans ces postes sont associes au journal daudit. Code T T T T T T T T Type AF CA OR OW PW RA RP SV Description Dfaut de droits Modification des droits dun objet Objet restaur Changement de propritaire Mot de passe utilis invalide Restauration dun objet avec modification des droits restauration dun programme adoptant les droits propritaire Modification dune valeur systme
du
Code U : Poste cr par lutilisateur, le type et la description font parties de la commande SNDJRNE. Code U Type Description
Annexe B - Les types de postes de la journalisation
261
LES TYPES DE POSTES DE LA JOURNALISATION
257
Index
ALWUPD
65 45
9
9337 137, 181
ALWVARLEN AND 196
A
ABSVAL 33 ACCPTH 176 ACCPTH 80 ACTGRP 63 ADDLFM 117, 122 ADDPFCST 159, 193, 195 ADDPFM 71, 72, 80 ADDPFTRG 168 ADDRDBDIRE 204 ALCOBJ 249 ALL 94 ALLOCATE 55 ALTER TABLE 79, 161, 193, ALTSEQ 35, 66 ALWDLT 65 ALWNULL 45
API 245, 267

APYJRNCHG
136, 139
ASCII 46 ASP 126, 135, 267
B
batterie 125 BETWEEN 197 bibliothque 8, 268
C
C2 178 CA/400 112 CALL 175 CCSID 47, 66 CHAIN 101 CHAIN 157
195
278
CHECK 37 checksum 126, 179
Index
279
chemin daccs 51, 69, 158, 245, 96, 119, 268, CHGLF 120, 249 CHGPF 67, 120, 249 CHGPFCST 163 CHGPFM 80 CHGQRYA 227 CHGRDBDIRE 204 CHKMSGID 37 CICS 247 cl 33, 161 Client Access/400 5, 71, 178, 226, 242 client/serveur 178 CLOF 233, 244 CLOSE 244 CLRPFM 76, 136, 140 CMP 94 CMTID 149 COLHDG 41 collection 188, 191 COMIT 146 COMMIT 146, 170 COMMIT 188, 203, 205, 208, 215 COMP 37 CONCAT 98 CONNECT 205, 250 contrainte dintgrit rfrentielle 157 contrle dintgrit 126, 179 contrle de validation 126, 145, 269 COUNT(*) 198 CPYF 40, 45, 78, 238, 249 Cration 8 CREATE INDEX 227 CRTDDMF 248 CRTDUPOBJ 77 CRTEDTD 38 CRTJRN 129, 135 CRTJRNRCV 129, 135 CRTLF 91, 115, 120, 227, 249
CRTPF 30, 49, 120, CRTSQLCOL 188 CRTSQLPKG 251 CRTSRCPF 249
227, 249
curseur 213
D
Date 42
DATFMT 42 DATSEP 42
DB2 42, 250 DB2/2 250 DB2/400 3, 250, 253 DB2/6000 250 DCLF 11, 45 DDM 10, 157, 247, 250, 269 DDS 9, 30, 47, 238, 248, 269 DECLARE 213, 221 dclencheur 126, 167 DELETE 202 DESCEND 34 DFT 40 DFTRDBCOL 191 DFU 5, 81, 111, 122, 164, 270 dictionnaire 31, 191 disque miroir 126, 181 DISTINCT 196, 217 DLCOBJ 249 DLTEDT 39 DLTF 76, 121, 249 DLTM 139, 140 DLTOVR 233, 243 DLTPCT 64 DLTSQLPKG 251 DMPDLO 270 DMPJOB 270 DMPOBJ 226, 270 document 270 dossier 270 DRDA 140, 167, 178, 185, 226, 250,
280
270 DROP 195

DROP PACKAGE 251 DSPDBR 245 DSPFD 35, 56, 76, 96,
116, 163, 176,
245 DSPFFD 76, 245 DSPJOBLOG 243 DSPJRN 133, 139 DSPOBJAUT 203 DSPOVR 243 DSPPFM 72, 76 DSPPGMREF 245 DTAMBRS 115 DUMP 270 DYNAMIC 219 DYNSLT 97, 109, 111
E
EBCDIC 46 EDTCDE 38
EDTOBJAUT 88, 203 EDTRBDAP 54, 141 EDTRCYAP 143 EDTWRD 38 END-EXEC 206 ENDCMTCTL 146 ENDJRNAP 142 ENTDTA 138
fichier d'impression 10 fichier logique 10, 83 fichier logique joint 106 fichier logique multiformat 100 fichier logique non-joint 91 fichier physique 10, 29 fichier source 71, 241, 270 FIFO 34, 64 FILE 138 FILETYPE 50 FLAG 51 FMTOPT 240 FMTSLR 104 FOR FETCH ONLY 217 FOR UPDATE OF 218 FORMAT 39 FRCACCPTH 53 FRCRATIO 53, 54 FROM 196, 199, 217 FROMFILE 238 FROMKEY 239 FROMMBR 239 FROMRCD 239 FTP 242, 251, 271
G
GENLVL 50 GOTO 212 GRANT 203 GROUP BY 199,
erreur 211 ET 95
EXECUTE EXIT 62 EXPCHK 66 EXPDATE 51,
227, 237 groupe dactivation 63 GRTOBJAUT 203
H
65
HAVING
F
214, 218 fichier 10 fichier d'affichage 10, 36
FETCH
199 Horodatage 43
I
IBM/36 104, 247
Index
281
IBM/38 247 IDDU 29 identificateur de format 64, 86 IFS 7 271 ILE 42 image aprs 128 image avant 128 IMMEDIATE 223 Impression 239 IN 197 INCCHAR 240 INCREL 240 INDEX 193 index 193, 227 indicateur 271 INFDS 164 INSERT INTO 201 intgrit 125 Internet 251, 254, 276 invalidation 146 INZPFM 40, 80, 136 IPL 54, 141, 144, 181, 271
LIFO 34, 64 LIKE 197, 227 longueur variable 44 LVLCHK 64
M
MAINT 52, 144 MAPFLD 236 MAXMBR 51, 71, MBR 51 MBROPT 239
161
membre 8, 68, 117, 238, 272 membre source 272 miniplan 226 mirroring 181 monomembre 70 MOVOBJ 136 multimdia 254 multimembre 70 MVS 250 NAMING 191
J
JDFTVAL 40, 109 JDUPSEQ 108 JFILE 107 JFLD 107, 237 JOBD 272 JOBQ 272 JOIN 107
N
NFS 70, 251 NFYOBJ 149 NOALTSEQ 35, 66 NULL 45, 192, 197
O
objet de notification 149, 273 ODBC 242 ODP 58, 233 Office Vision/400 5, 273 omission 93 OMTJRNE 136, 138 OPEN 213 244 OPNDBF 244 OPNQRYF 45, 65, 112, 119, 144, 226, 231, 244
jointure 237 journal 128, 155, 272 journalisation 69, 126, 127, 143
L
LAN Serveur 7 LANGID 35, 66 LCKLVL 146 LDA 272
282
optimiseur 226 OPTIMIZE 217 OR 196 ORDER BY 197, 218, 227 OS/2 8, 247 OSI 251, 253 OU 95 OUTQ 273 OVRDBF 59, 62, 65, 66, 73, 121, 233, 242 OVRDSPF 65 OVRPRTF 65
QPJOBLOG 274 QRYSLT 235 QSECURITY 182 QSQJRN 191 QSQLTEMP 206 QSYS 66, 187, 274 QSYSOPR 55, 181, 228 QSYSPRT 206, 239 QSYSTRNTBL 99 QTEMP 144, 206
P
package 251 PAG 59 page de code 46 Partage de format 39 PCS/400 5, 112, 226, 242, 273 performance 136 PFILE 91 PGMQ 274 plans daccs 226 POSDBF 244 poste 127 PREPARE 221, 224 PRINT 239 PRTCMDUSG 245 PRTSQLINF 228 PTF 274
Query 5, 45, 73, 81, 112, 144, 189, 226, 274 Query Manager 189 QUSRSYS 35
R
RAID5 126, 181 RANGE 37, 94 RCVF 18 RCVNETF 251 READ 249 READE 101 rcepteur de journal 128 RECOVER 53, 120, 141 REF 31, 36 REFACCPTH 96 REFFLD 31, 36 REFSHIFT 37 RENAME 98 restauration 274 RETRN 62, 175 REUSEDLT 64 REVOKE 204 Rexx 205 RGZPFM 15, 64, 80, 139, 140 RMVJRNCHG 136, 140 RMVM 76, 80, 121, 136 RMVPFCST 163 RNMM 80 RNMOBJ 136 ROLBK 146
Q
QAUDCTL 178 QAUDJRN 178 QAUDLVL 178 QCASE256 35 QCPFMSG 171 QDBLDBR 77 QDDSSRC 49 QGPL 49, 274
Index
283
ROLLBACK 146, 170, ROWS VALUES 211
203, 205
RPG 85 RPG IV 44, 168, 205 RPG/400 43, 45, 168, 205 RSTLIB 80 RSTOBJ 80 RUNSQLSTM 188, 190, 203 RVKOBJAUT 203
S
SAA 267, 275 sauvegarde 121, 137, 275 SAVACT 176 SAVCHGOBJ 137, 176 SAVLIB 80, 136, 137, 176 SAVOBJ 80, 136, 137, 176 SBMJOB 190 SBMRMTCMD 249 SCHEMA 194 SCROLL 219 SDA 275 scurit 5 87, 125, 177, 203, 246 SELECT 195, 213, 217, 221 SELECT INTO 208, 223 slecteur de format 104 Slection 93 SGBDR 3, 83, 205, 250, 268 SHARE 60 SIZE 55 SMAPP 143 SNADS 275 SNDF 18 SNDJRNE 138 SNDNETF 251 SNDPGMMSG 171 SNDRCVF 18 sous-fichier 149 SQL 5, 45, 70, 81, 119, 144, 157, 185, 275 SQL package 275
SQL/400 185 SQL/DS 42, 250 SQLCA 211, 214, 218 SQLCBL 206 SQLCODE 211 SQLDA 223 SQLRPG 206 SQLRPGLE 206 SRCMBR 49 SRCOPT 241 SRCSEQ 241 SRTSEQ 35, 66 STOPRUN 62 STRCMTCTL 146, 203 STRJRNAP 129, 142 STRJRNPF 129, 136, 138 STRQM 189 STRQMQRY 190 STRQRY 81 STRSQL 188, 189, 203 STRSST 56 SYSTABLES 196
T
table 192 table de conversion 66 TCP/IP 242, 251, 253, 276 Time 42 Timestamp 42 TIMFMT 42 TIMSEP 42 TOFILE 238 TOKEY 239 TOMBR 239 TORCD 239 tri 34, 66, 237 trigger 167, 269, 276 TYPE 8, 138
284
Union 93 UNIQUE 34, 52, 89, 159 UNIT 56 UPDAT 164, 249 UPDATE 201, 219 User Index 246 User Space 77, 276 USING 224
V
validation 146 VALUES 94 VIEW 193
W
WHENEVER 212 WHERE 196, 200, 227 WRITE 104, 164, 249 WRKJRN 133, 139 WRKJRNA 132 WRKPFCST 163 WRKRDBDIRE 204, 250
Index
285
INDEX
277

BD 400

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

BD 400

Transféré par

Droits d'auteur :

Formats disponibles

Prface

Table des matires

DB2/400 ET LA GESTION DES DONNES SUR AS/400

Table des matires

Exemple............................................................................................................................ 73 Conclusions ...................................................................................................................... 75

DB2/400 ET LA GESTION DES DONNES SUR AS/400

Table des matires

DB2/400 ET LA GESTION DES DONNES SUR AS/400

Table des matires

DB2/400 ET LA GESTION DES DONNES SUR AS/400

QSYS create FICH1

AVANT-PROPOS ................................................................................................................1 NEOLOGISMES ET TYPOGRAPHIE .............................................................................................2

DB2/400 : la base de donnes de lOS/400

DB2/400 ET LA GESTION DES DONNES SUR AS/400

Les caractristiques de DB2/400

DB2/400 ET LA GESTION DES DONNES SUR AS/400

La base de donnes distribue

DB2/400 ET LA GESTION DES DONNES SUR AS/400

DB2/400 ET LA GESTION DES DONNES SUR AS/400

*LIB *PGM *FILE

Figure 2.1 : organisation logique des donnes pour l'OS/400.

DB2/400 ET LA GESTION DES DONNES SUR AS/400

DB2/400 ET LA GESTION DES DONNES SUR AS/400

la modification des constantes, des commentaires, des couleurs ;

DB2/400 ET LA GESTION DES DONNES SUR AS/400

Ajout dun enregistrement

DB2/400 ET LA GESTION DES DONNES SUR AS/400

Figure 2.3 : compactage d'un fichier par la commande RGZPFM.

Liens avec la programmation

Exemples en langage de contrle

Utilisation d'un fichier physique ou logique

DB2/400 ET LA GESTION DES DONNES SUR AS/400

Exemple 2.2 : utilisation d'un fichier base de donnes en langage de contrle.

DB2/400 ET LA GESTION DES DONNES SUR AS/400

Utilisation d'un fichier d'affichage

Exemple 2.3 : architecture dun programme CLP utilisant un fichier daffichage

Programme en langage de contrle

Exemple 2.4 : programme en langage de contrle de gestion d'un cran.

DB2/400 ET LA GESTION DES DONNES SUR AS/400

Utilisation de la cl Type de fichier

Description du fichier Ajout denregistrement Utilisation de la cl Type de fichier

Utilisation d'un fichier physique ou logique

DB2/400 ET LA GESTION DES DONNES SUR AS/400

Lecture dun enregistrement

Modification dun enregistrement

Ajout dun enregistrement

DB2/400 ET LA GESTION DES DONNES SUR AS/400

FMT1 1 NUMCLI ZONE1 ZONE2 5 0 5 5 35 10 22

Niveau Fichier Niveau Format Niveau Zone Niveau Cl Niveau Slection

VALUES(CPT 30J 60J + VIR) REFSHIFT(X)

DB2/400 ET LA GESTION DES DONNES SUR AS/400

NOMCLI SOLDE FMT3

CF10(10 impression) Nom du client Solde : TEXT(Touches de fonction) F3=Fin F10=Impression

Les types de donnes

DB2/400 ET LA GESTION DES DONNES SUR AS/400

DB2/400 ET LA GESTION DES DONNES SUR AS/400

DB2/400 ET LA GESTION DES DONNES SUR AS/400

Les fichiers physiques

DB2/400 ET LA GESTION DES DONNES SUR AS/400

Les tapes de la cration d'un fichier physique par DDS

R FMT1 NOMCLI NUMCLI SOLDE

Membre source Type PF

Figure 3.1 : les tapes de la cration d'un fichier physique.

La codification des fichiers physiques

LIB PGM *FILE