Les données et l`as400 le SGBDR DB2/400

Transcription

OS400-04
LES DONNÉES ET L'OS400
le SGBDR DB2/400
Auteur : Dominique Vignez
© Institut de Poly-informatique (1995)
OS40004.DOC
DB2/400 les données et l'OS400
Cette page est laissée intentionnellement blanche
2
Table des matières
1
2
3
4
5
6
7
8
9
10
Introduction................................................................................................................ 7
Traitement des données par l'AS400 ......................................................................... 7
Description des fichiers ............................................................................................. 8
3.1
Description au niveau enregistrement............................................................ 8
3.2
Description au niveau champ......................................................................... 8
3.2.1 types de données supportés ................................................................ 8
Organisation de la Base de Données AS400.............................................................. 9
4.1
Notion de base de données............................................................................. 9
Méthodes de description des données au système ..................................................... 10
5.1
Outils d'aide à la gestion des descriptions de données................................... 10
5.1.1 Dictionnaire des données ................................................................... 10
5.1.2 Fichier de références de zones ........................................................... 10
5.2
Utilisation d’Operation navigator .................................................................. 11
5.3
Terminologie.................................................................................................. 11
OS400 DDS ............................................................................................................... 13
6.1
Niveaux informations dans un membre source de description de
données ...................................................................................................................... 14
6.1.1 Créer un membre PF ou LF................................................................ 16
6.2 .............................................................................................................................. 17
6.2.1 Syntaxe d'une ligne de spécification DDS ......................................... 17
OS400 IDDU ............................................................................................................. 20
SQL/400..................................................................................................................... 22
Description à l'aide de Query Manager...................................................................... 22
Description des fichiers système................................................................................ 24
10.1 Fichier QIDCTP10......................................................................................... 24
10.2 Fichier QIDCTP20......................................................................................... 24
10.3 Fichier QIDCTP21......................................................................................... 25
10.4 Fichier QIDCTP25......................................................................................... 25
10.5 Fichier QIDCTP30......................................................................................... 25
10.6 Fichier QIDCTP31......................................................................................... 26
10.7 Fichier QIDCTP51......................................................................................... 26
10.8 Fichier QIDCTP52......................................................................................... 26
10.9 Fichier QIDCTP53......................................................................................... 26
10.10
Fichier QIDCTL76 .................................................................................... 27
10.11
Fichier QIDCTL80 .................................................................................... 27
10.12
Fichier QIDCTL81 .................................................................................... 27
10.13
Fichier QIDCTL82 .................................................................................... 27
10.14
Fichier QIDCTL84 .................................................................................... 27
10.15
Fichier QIDCTL86 .................................................................................... 27
10.16
Fichier QIDCTL88 .................................................................................... 28
10.17
SYSINDEXES........................................................................................... 28
10.18
SYSKEYS ................................................................................................. 28
10.19 .......................................................................................................................... 29
10.20
SYSCOLUMNS ........................................................................................ 29
10.21
SYSTABLES............................................................................................. 29
10.22 .......................................................................................................................... 30
10.23
SYSVIEWDEP .......................................................................................... 31
10.24
SYSVIEWS ............................................................................................... 31
3
11
12
13
14
15
16
17
18
Évolutions relatives au support de DB2 en V3R1M0................................................ 32
11.1 Support de IFS (Integrated File System)........................................................ 32
11.2 Réorganisation des tables système ................................................................. 32
11.3 QABDCCST .................................................................................................. 32
11.4 QADBFCST................................................................................................... 32
11.5 QADBIFLD.................................................................................................... 33
11.6 QADBKFLD .................................................................................................. 33
11.7 ............................................................................................................................ 33
11.8 QADBXRDBD .............................................................................................. 33
11.9 QADBXREF .................................................................................................. 33
11.10
QADBPKG................................................................................................ 33
11.11
QADBFDEP .............................................................................................. 33
11.12
Support des contraintes d'intégrité référentielle ........................................ 33
11.13
Support des triggers ou déclencheurs ........................................................ 34
11.14 .......................................................................................................................... 35
11.15
Les messages escape du SGBD ................................................................. 35
11.16 .......................................................................................................................... 36
11.17 .......................................................................................................................... 36
11.18
Procédures cataloguées .............................................................................. 36
11.19
Validation à deux phases ou two phases commit ...................................... 36
Les fichiers de l'OS400 .............................................................................................. 37
12.1 ............................................................................................................................ 37
12.2 Types de fichiers ............................................................................................ 37
12.3 Accès aux fichiers .......................................................................................... 38
12.4 CONTRÔLE DES ACCÈS FICHIERS ......................................................... 39
12.4.1 Open feedback area.......................................................................... 40
12.4.2 I/O feedback area ............................................................................. 40
Les fichiers de données .............................................................................................. 41
13.1 Structure......................................................................................................... 41
Description................................................................................................................. 41
14.1 fichiers physiques........................................................................................... 41
14.2 Structure......................................................................................................... 42
Mots clé...................................................................................................................... 43
15.1 Niveau fichier................................................................................................. 43
15.2 Niveau format d'enregistrement ..................................................................... 45
15.3 Niveau zone ................................................................................................... 47
15.4 Niveau clé ...................................................................................................... 53
fichiers logiques ......................................................................................................... 53
16.1 Structure......................................................................................................... 53
16.2 Logiques joints............................................................................................... 53
16.3 Conversions de type de données .................................................................... 55
Mots clé...................................................................................................................... 55
17.1 Niveau fichier................................................................................................. 55
17.2 Niveau enregistrement ................................................................................... 56
17.3 Niveau joint.................................................................................................... 56
17.4 Niveau champ ................................................................................................ 57
17.5 Niveau clé ...................................................................................................... 58
17.6 Niveau sélection/omission ............................................................................. 61
Autres fonctions base de données .............................................................................. 62
18.1 National Language Support............................................................................ 62
4
19
20
21
18.2 Predictive Query Governor ............................................................................ 62
18.3 Amélioration des performances ..................................................................... 62
18.4 Bases de données distribuées ......................................................................... 62
18.5 Passerelles vers d'autres SGBDR................................................................... 63
18.6 Data Propagator.............................................................................................. 63
18.7 Opticonnect .................................................................................................... 63
Bases de données parallèles ....................................................................................... 64
19.1 La base de données SMP (Symetric Multiprocessing Parallel) ..................... 64
19.2 La base de données faiblement associée ........................................................ 64
Sécurité des données .................................................................................................. 65
20.1 La journalisation ............................................................................................ 65
20.2 La protection des chemins d'accès par le système (SMAPP)......................... 65
20.3 Le contrôle de validation................................................................................ 65
20.4 DASD de technologie RAID 5....................................................................... 66
Limitations ................................................................................................................. 67
5
6
7
1 Introduction
De par son caractère intégré, situé pour partie au dessus du MI et pour partie à l'intérieur du
SLIC, la base de données de l'AS400 atteint un niveau d'efficacité plus important qu'une autre
base de données qui serait construite au dessus du système d'exploitation.
La base de données de l'AS400 a été conçu pour le S38 dès 1975 par Perry Taylor. A cette
époque E.F. Codd travaillait pour IBM sur un projet appelé System/R et avait décrit un
système relationnel de table à deux dimensions, sur laquelle on pouvait réaliser quatre
opérations (order, selection, projection, join). Perry Taylor entra en contact avec Codd pour lui
faire part de ses propres travaux et lui demander d'unir leurs efforts. Mais Codd le pris de haut
annonçant que les bases de données relationnelles ne pouvaient être conçues que pour les gros
systèmes et qu'un petit système n'avait besoin que d'un tri et d'une fusion de fichiers.
La première base de données relationnelle à être installée sur un ordinateur fut celle du S38 en
1978, mais sans l'opération join. Trois ans plus tard, la base de données du système/R fut
commercialisée sous le nom de DB2 et comme elle possédait les quatre opérations, il fut
décrété qu'elle était finalement la première base de données relationnelle au monde.
Comme il n'existait pas d'interface standard aux bases de données relationnelles à l'époque où
la base de données du système 38 a été lancée, il a fallu développer une interface native : les
DDS. Les spécifications du langage SQL ne sont venues que plus tard et une décennie a été
nécessaire à leur stabilisation. Ceci explique que les DDS sont livrées encore aujourd'hui en
standard alors que le kit de développement SQL est fourni en option.
Cette nécessité historique fait que longtemps le SQL a été moins performant et quasiment
inutilisé sur AS400. La réécriture du SGBD DB2/400 avec la V3.R1. de l'OS400 a gommé
cette différence. DDS et SQL sont maintenant au même niveau de performances sur l'AS400.
2 Traitement des données par l'AS400
L'AS400 est une machine conçue pour s'intégrer dans l'AUA d'IBM (Architecture unifiée
d'applications) et pouvant assurer la compatibilité avec la gamme 3X ou avec la gamme gros
systèmes et même micro sous OS/2 ou AIX pour RS/6000.
Sur une même machine il est donc possible de gérer les données de plusieurs façons suivant
les finalités recherchées.
Ainsi, si l'on utilise des programmes utilisateurs provenant d'un 3X ou des produits sous
licence IBM ou si l'on utilise des programmes s'inscrivant dans l'AUA comme CICS par
CSP/AE (à partir de la version OS/400 2.2), on ne décrira pas les données de la même manière
et on ne les traitera pas non plus de la même manière.
8
3 Description des fichiers
3.1 Description au niveau enregistrement
Elle correspond à l'utilisation traditionnelle sans base de données. Seule la longueur de
l'enregistrement est décrite au système. Le système ne connaît rien des champs contenus dans
le fichier. La description des champs n'étant donnée qu'à l'intérieur des programmes. Cette
façon de procéder est appelée "fichiers à description interne". Dans ce cas les données sont
strictement dépendantes des programmes.
3.2 Description au niveau champ
Elle correspond à l'utilisation avec base de données déjà utilisée sur le système 38. L'ensemble
des éléments à décrire pour un champs comprend :
- le nom,
- la longueur,
- le type,
- les domaines de validité,
- un texte descriptif.
Cette façon de procéder est appelée "fichiers à description externe". Dans ce cas les données
sont indépendantes des programmes.
3.2.1
types de données supportés
Le type de données est indiqué en colonne 35 d'une spécification de description de données
(A) voir annexes les types possibles sont :
- P numérique décimal packé,
- S numérique décimal zoné,
- B numérique binaire,
- F numérique flottant,
- A alphabétique,
- H hexadécimal,
- L date,
- T heure,
- Z horodatage.
Si le type de données n'est pas explicitement indiqué le système attribuera par défaut le type A
(alpha) si ne nombre de décimales (colonne 36,37) est blanc, ou packé si le nombre de
décimales est de 0 à 31.
Indiquer 0 décimale en colonnes 36 37 désigne un entier pour des zones définies en packé,
zoné ou binaire.
Si le type est F (virgule flottante) il faut spécifier le mot clé FLTPCN pour indiquer la simple
ou la double précision du nombre flottant.
9
Le type hexadécimal permet d'indiquer au système qu'il ne doit pas interpréter le contenu de
ce champ et le restituer tel quel. Dans la plupart des cas un champ défini en hexadécimal sera
traité sur les mêmes règles qu'un champ alpha.
4 Organisation de la Base de Données AS400
Sur AS400 il existe 4 méthodes pour décrire les données :
- à l'aide de sources DDS suivis d'une compilation
(CRTPF, CRTLF),
- à l'aide de IDDU,
- à l'aide de SQL,
- à l'aide de Query Manager.
Suivant la méthode utilisée l'environnement système et les possibilités sont différentes mais
toujours complémentaires.
4.1 Notion de base de données
Sur AS400 une base de données est un ensemble de fichiers physiques et logiques contenus
dans une même bibliothèque.
Conceptuellement une base de données ne peut pas contenir d'autres bases de données.
L'arborescence est donc limitée à sa plus simple expression. Seule la base de données du
système (QSYS) qui est la racine, peut contenir d'autres bases de données.
Le gestionnaire système de la base données, n'a donc à gérer que deux niveaux hiérarchiques.
Au niveau le plus bas (QSYS) le gestionnaire dispose de deux fichiers physiques.
QADBXREF (description des fichiers) contenant un enregistrement de 127 octets pour
chaque fichier existant collectant les renseignements suivants :
- nom du fichier,
- nom de la librairie,
- nom du dictionnaire,
- nom du propriétaire,
- texte descriptif,
- type de fichier (physique, logique, table, vue, index),
- statuts de lien (Externe, Programme, sans),
- type du dictionnaire (Iddu, Crtdtadct, Sql, Xmigration,
- type fichier (Data, Source),
- nombre de champs,
- nombre de champs clé,
- longueur d'enregistrement,
- identificateur interne dans dictionnaire (n° record).
10
QADBFDEP (relations entre les fichiers) contenant un enregistrement de 41 octets pour
chaque fichier basé sur un autre.
- nom du fichier de base,
- librairie du fichier,
- nom du fichier dépendant,
- librairie du fichier dépendant,
- type de dépendance (Données, Vue, Index).
Deux fichiers logiques sont basés sur QADBXREF se sont QADBXFIL, QADBXDIC et deux
fichiers logiques sont basés sur QADBFDEP se sont : QADBLDEP et QADBLDNC pour
simplifier les accès.
Lorsque l'on décrit les données avec la méthode des DDS, seule cette configuration est en
oeuvre associée à la description des champs contenue dans le fichier lui même.
5 Méthodes de description des données au système
Si vous désirez décrire un fichier uniquement au niveau enregistrement, vous pouvez utiliser
le paramètre de longueur d'enregistrement (RCDLEN) en utilisant la commande de création de
fichier physique CRTPF.
Si vous désirez décrire un fichier au niveau champs, vous pouvez utiliser plusieurs méthodes :
l'utilitaire IDDU (interactive data description utility), les commandes SQL/400, ou les DDS
(data description specifications).
Les DDS offrant le maximum des possibilités de descriptions offertes au programmeur, c'est
souvent cette méthode que vous utiliserez.
5.1 Outils d'aide à la gestion des descriptions de données
Afin d'éviter les doubles définitions de données et dans un souci de standardisation, il est
possible d'utiliser soit un dictionnaire de données soit un fichier de références de zones.
5.1.1
Dictionnaire des données
Un fichier à description interne peut être décrit dans un dictionnaire de données pour le détail
du ou des formats d'enregistrements surtout si ce fichier doit être utilisé par QUERY/400,
PCS/400 ou DFU.
De même un fichier à description externe peut également être décrit dans un dictionnaire. Le
système s'assurant que les deux définitions soient bien identiques.
5.1.2 Fichier de références de zones
L'ensemble des détails de description des champs peut être contenu dans ce fichier, évitant
ainsi au programmeur des redéfinitions longues et sources d'erreurs.
11
L'utilisation de ce fichier accroît la productivité du programmeur et garanti l'uniformité des
descriptions de données d'un programmeur à l'autre.
5.2 Utilisation d’Operation navigator
Operation Navigator permet de gérer la base de données par interface graphique. Les requêtes
SQL sont générées automatiquement par l’interface. A partir de la V4.R4. c’est l’outil le plus
puissant de l’AS400 pour gérer les possibilités de DB2 Universal DataBase.
5.3 Terminologie
Suivant la méthode employée les notions logiques de mêmes entités peuvent être nommées
différemment.
La liste suivante donnera les termes pour une organisation traditionnelle puis selon l'OS400
puis selon SQL .
répertoire
fichier
index secondaire
enregistrement
item
librairie
fichier physique
fichier logique
format
champs
collection
table
vue
rangée ou tupple
colonne ou attribut
12
Ces termes bien que regroupant des conceptions identiques ne sont pas simplement des
homonymes mais bien des entités différentes qui ne peuvent être utilisées l'une pour l'autre.
Ces parallèles ne sont faits que pour aider à la compréhension.
Pour de plus amples informations sur ce sujet, consultez les brochures IBM programming data
base guide, programming data management guide.
13
6 OS400 DDS
Les fichiers à description externe peuvent être décrits en utilisant le langage de description de
données. Il s'appelle :
DDS : Data Description Spécification en anglais.
SDD : Spécification de Description de Données en français.
Il sert à décrire les données dans des membres source :
. de Base de données
. d'affichage
. d'impression
. de communications
... etc.
: membres source PF et LF.
: membres source DSPF.
: membres source PRTF.
: membres source ICFF.
Chaque ligne d'un membre de donnée = une spécification.
Chaque spécification contient la lettre 'A' en colonne 6.
L'utilisation des DDS vous permet d'intervenir dans les descriptions au niveau du champs, de
l'enregistrement et du fichier. Ce n'est que par l'utilisation des DDS qu'il est possible de
décrire les clés du chemin d'accès d'un fichier logique par exemple. Ceci contrairement à SQL
qui vous permettra de décrire des vues.
14
La colonne 17 de la spécification A peut contenir :
- R pour indiquer la description d'un enregistrement (Record),
- K pour indiquer la description d'une zone clé,
- J pour indiquer la description d'un joint,
- S pour indiquer la description d'une sélection,
- O pour indiquer la description d'une omission.
Les colonnes 19 à 28 peuvent contenir un nom d'enregistrement ou un nom de champ.
La colonne 29 peut contenir un "R" pour indiquer que la description du champ est à
rechercher dans un autre fichier soit dans le fichier indiqué au mot clé REF, soit par rapport à
une autre zone décrite précédemment au dans un autre fichier Indiqués au mot clé REFFLD.
Les colonnes 30 à 34 peuvent contenir la longueur de la zone (cadrée à droite).
La colonne 35 indique le type de données (voir ci-dessus types de données).
Les colonnes 36 37 peuvent contenir le nombre de décimales (cadrée à droite) pour la
description d'une zone numérique. Un nombre de décimales égal à zéro indique une zone
numérique entière.
La colonne 38 décrit l'usage de la zone et n'est généralement pas utilisée pour les fichiers base
de données. Les valeurs possibles sont :
- I (Input) entrée,
- O (Output) sortie,
- B (Both) entrée sortie,
- H (hidden) caché,
- M (Message),
- P (Program to system),
- N (Neither) ni entrée ni sortie.
Les colonnes 39 à 41 indiquent le no de ligne alors que les colonnes 42 à 44 indiquent le no
de colonne. Ces informations ne sont utilisées que pour les fichiers écrans ou imprimantes et
pas pour les fichiers base de données.
Les colonnes 45 à 80 sont utilisées pour indiquer les mots clé. Voir ci-dessous les différents
mots clé et leur niveau d'usage.
Pour de plus amples informations sur les DDS consultez la brochure IBM programming data
description specifications reference SC-41-9620.
6.1 Niveaux informations dans un membre source de description de
données
15
Un membre source de description de données contient des informations organisées en
niveaux.
Ces niveaux ont un ordre à respecter.
Certains niveaux peuvent être ignorés s'ils ne sont d'aucune utilité dans un membre source.
Un membre PF contient 4 niveaux :
- informations de niveau fichier.
- informations de niveau format d'enregistrement .
- informations de niveau zone.
- informations de niveau clé.
Un membre LF contient 5 niveaux :
- informations de niveau fichier.
- informations de niveau format d'enregistrement .
- informations de niveau zone.
- informations de niveau clé.
- informations de niveau sélection.
16
6.1.1 Créer un membre PF ou LF
La création d'un membre source PF permet la création d'un fichier de données.
1) Avant de créer un membre PF, il faut connaître les informations suivantes sur le fichier :
- le fichier répertoire qui contient la description des zones fichiers,
- s'il y a présence de clé : unicité de la clé ou non,
- le nom du format d'enregistrement à donner au fichier,
- le nom des zones composant l'enregistrement,
- le nom de ou des zone (s) composant la clé (optionnel ),
- la ou les sélections à faire sur les données ( pour LF uniquement ).
2) Il faut organiser ces informations en niveaux :
Au niveau fichier :
- donner le nom du répertoire de description des zones,
- dire si la clé est unique ou pas ( en cas de présence de clé),
- donner autres infos. de niveau fichier.
Au niveau format d'enregistrement :
- donner le nom du format d'enregistrement,
- donner autres infos. de niveau format d'enregistrement.
Au niveau zone, pour chaque zone :
17
- donner le nom de la zone,
- si la zone est référencée :
- dire si elle fait référence au répertoire cité au niveau fichier ou si elle fait
référence à une autre zone,
- si la zone n'est pas référencée :
- donner sa longueur et son type;
- donner infos complémentaires. au niveau zone.
Au niveau clé :
- donner la ou les zones composant la clé (cette ou ces zones doivent faire partie de
l'enregistrement ),
- donner autres infos. au niveau clé.
Au niveau sélection omission :
- décrire la/les sélections et/ou omissions de données.
3) Créer le membre PF ou LF sous PDM :
Créer un nouveau membre de type PF ou LF.
Pour saisir une ligne : insérer une ligne avec l'invite DP : IPDP
(voir pages suivantes pour la syntaxe DDS)
4) Compiler le membre PF ou LF pour créer le fichier BD :
utilisez l'option 14 de PDM (si besoin F4 pour les options et optimisations).
Attention : il y a un ordre de création des différents fichiers de la BD.
- créer d'abord le répertoire de données,
- créer ensuite les fichiers Physiques,
- créer enfin les fichiers Logiques.
6.2
6.2.1
Syntaxe d'une ligne de spécification DDS
18
19
20
7 OS400 IDDU
Les fichiers physiques peuvent être décrits en utilisant IDDU. L'avantage d'utiliser IDDU est
que c'est une méthode interactive avec accès par menus pour décrire les données. Il se peut
également que des utilisateurs connaissant le système 36 en aient l'habitude et préfèrent cette
méthode. De plus IDDU autorise la description de formats multiples en relation avec
QUERY/400, PCS/AS/400 (PC Support) et DFU (data file utility).
Si vous utilisez IDDU pour décrire vos fichiers, les définitions de fichiers deviennent des
éléments d'un dictionnaire de données OS/400. Si vous désirez de plus amples informations à
ce sujet consultez la brochure IBM IDDU user's guide.
Lorsque l'on utilise la méthode IDDU, une base de données utilisateur, donc une librairie
contient en plus des fichiers de données les objets suivants :
- un dictionnaire de données (DTADCT) portant le nom de la base de données.
- 10 fichiers physiques qui sont :
QIDCTP02 commentaires longs des fichiers, enregistrements et champs,
QIDCTP10 descriptions des champs,
QIDCTP20 descriptions des enregistrements,
QIDCTP21 relations des champs et des enregistrements séquence des champs
et mode de traitement,
QIDCTP25 séquence et mode de traitement des enregistrements,
QIDCTP30 descriptions des fichiers,
QIDCTP31 relations des enregistrements et fichiers,
QIDCTP51 zones clé d' un enregistrement,
QIDCTP52 texte de la commande SQL ayant créée un enregistrement,
QIDCTP53 relations entre un enregistrement et les fichiers physiques sur
lesquels il est basé.
- 7 fichiers logiques basés sur les précédents :
QIDCTL76 liste des champs par alias basé sur P10,
QIDCTL80 liste des champs par nom et par id interne de dictionnaire basé sur
P10,
QIDCTL81 liste des enr. basé sur P20,
QIDCTL82 liste des fichiers basé sur P30,
QIDCTL84 liste des enr. utilisant un champ basé sur P20, P21,
QIDCTL86 liste des fichiers utilisant un enr. basé sur P30, P31,
QIDCTL88 liste des fichiers utilisant un champ basé sur P20, P21, P30, P31.
Ces objets sont nécessaires à l'utilitaire IDDU pour assurer sa fonction de description de
données interactive.
Mais IDDU n'est capable de créer que des fichiers physiques. Par contre il peut gérer les
définitions de fichiers logiques. Un fichier créé par la méthode des DDS peut voir ses
définitions gérées par IDDU à la condition que celles ci soient entrées dans le dictionnaire par
la commande ADDDTADFN.
21
Néanmoins les fichiers partageants un chemin d'accès, ayant une séquence de classement
alternée ou étant en union, les fichiers joints et les fichiers logiques en select ou en project ne
sont pas gérables par IDDU.
22
8 SQL/400
Le langage de requête structuré SQL/400 peut être utilisé pour pour décrire une base de
données AS/400. SQL/400 supporte les instructions pour décrire les champs d'une base de
données, et pour créer les fichiers.
Si l'application que vous développez doit s'inscrire dans un contexte de portabilité entre
systèmes, il sera préférable de décrire vos données par SQL.
Pour de plus amples informations à ce sujet, consultez la brochure IBM SQL/400
programmer's guide.
Lorsque l'on utilise la méthode SQL, l'environnement s'enrichi encore et la base de données
devient une collection par adjonction des éléments suivants :
- QSQJRN journal associé au contrôle de validation SQL,
- QSQJRN0001 récepteur de journal,
- 8 fichiers logiques assurants la comptatibilité avec la norme SQL et dont les
fonctions et contenus sont redondants avec ceux de IDDU,
QSQTABLES basé sur P02 et P30;
QSQCOLUMNS basé sur P10, P02, P20, P30, P31, QADBXREF;
SYSCOLUMNS mêmes bases que le précédent;
SYSINDEXES basé sur P30, QADBXREF, QADBFDEP;
SYSKEYS basé sur P02, P10, P20, P51, QADBXREF;
SYSTABLES basé sur P30, QADBXREF;
SYSVIEWDEP basé sur P30, QADBXREF, QADBFDEP;
SYSVIEW basé sur P30, P52, QADBXREF.
Cette configuration est nécessaire pour créer des tables, des vues, des enregistrements par
SQL.
Mais pour gérer les données en lecture, en mise à jour ou en ajout à l'aide de SQL, il n'est pas
indispensable que ces dernières soient incluses dans une collection. SQL400 est capable de
gérer les données de l'AS400 quelque soit leur mode de définition.
9 Description à l'aide de Query Manager
Query Manager est un outil offrant une interface utilisateur pour utiliser le langage SQL. Il
offre les mêmes possibilités que IDDU et SQL réunis, sans avoir recours aux fichiers
systèmes. Par contre et s'en est la contrepartie, il est un peu plus lent d'exécution car chaque
information doit faire l'objet d'un traitement pour être accessible au lieu d'avoir à effectuer une
simple lecture de fichier.
L'accès à Query Manager se fait grâce à la commande STRQM (démarrer Query Manager).
En choisissant le choix 3 (gestion des tables QM) du menu qui s'affiche, une fenêtre permet
d'indiquer la collection ou la bibliothèque sur laquelle on désire travailler.
23
L'affichage d'un choix de bibliothèque dans une liste est possible par l'intermédiaire de la
touche F4.
Il est possible ensuite de créer un fichier physique par l'option 1 (création de table).
10 Description des fichiers système
10.1 Fichier QIDCTP10
Longueur d'enregistrement : 535 octets
nom externe du champ
id interne du champ
flag interne de delete
fonction de création
date de création
heure de création
id créateur
date dernière modification
heure dernière modification
id dernier modifieur
type général de donnée (1=char, 2=numérique)
type détail de donnée
majuscule par défaut
longueur externe
longueur interne
nbre de décimales
type de donnée SQL
longueur SQL
précision SQL
valeur nulle possible (Y=oui, N=non)
code d' édition
séparateur de date et heure
symbole de point décimal
séparateur de milliers
apparition du signe négatif
signe négatif gauche
signe négatif droit
impression de la valeur zéro
remplacement des zéros non significatifs
remplacement de la valeur zéro
option d' affichage des zéros négatifs
affichage du symbole monétaire
symbole monétaire gauche
symbole monétaire droit
mot d' édition
longueur entête 1 de champ
entête 1 de champ
entête 2 de champ
entête 3 de champ
nom alias
Longueur d' enregistrement 123 octets
24
nom externe de l'enregistrement
id interne de l' enregistrement
texte descriptif
fonction de création
date de création
heure de création
id du créateur
date de dernière modif
heure de dernière modif
id du dernier modificateur
code de révision du fichier physique 21
code de révision du fichier physique 25
réserve
reserve
id interne d' enregistrement
code de révision interne
id interne de champ
type de fichier (D=dbase)
séquence relative de sortie
séquence relative d' entrée
usage du champ
modifiable par SQL (Y=oui, N=non)
n° de référence de joint
id interne de champ
n° relatif de séquence
type de fichier (D=dbase)
position relative dans le champ
opérateur de comparaison (EQ, NE, ZN, NZ, DG, ND)
valeur test id enregistrement
continuation et/ou (1=and, 2=or)
nom externe du fichier
id interne du fichier
texte descriptif
date de création
heure de création
id du créateur
25
date dernière modif
heure dernière modif
id du dernier modificateur
type de fichier (1=physique, 2=logique)
accès base de données (1=séquentiel, 2=par clés)
type de joint (1=inner join, 2=left outer join)
vérification SQL (Y=oui, N=non)
clés en double (D=oui, U=non)
séquence des clés en double (F=fifo, L=lifo)
code de révision fichier physique 31
réserve
réserve
réserve
définition fichier SQL
Longueur d'enregistrement 27 octets
id interne fichier
code révision interne
N° de séquence relatif
longueur d' enregistrement 40 octets
id interne fichier
id interne de champ
n° de séquence relatif
ordre de tri de la clé (A=ascendant, D=descendant)
attribut de clé (S=signée, U=non signée, A=alpha, D, Z)
id interne de fichier
texte de la commande SQL de création
id interne fichier
nom du fichier de base
nom de la librairie du fichier de base
26
id interne du fichier physique de base
séquence de référence de joint (0=logique)
10.10 Fichier QIDCTL76
Vue logique de QIDCTP10 longueur enr. 30 octets,
longueur clé 30 octets
clé : Q76GUA
Index de QIDCTP10 longueur enr. 535 octets,
clé : Q10DEN,Q10IDI nom externe zone, id interne
clé : Q20REN,Q20IRI nom externe enr., id interne
clé : Q30FEN,Q30IFI nom externe fichier, id interne
Vue jointe sur QIDCTP21/QIDCTP20
longueur enr. 101 octets
clé : Q84IDI
joint : QIDCTP21/Q21IRI→ QIDCTP20/Q20IRI
id champ interne
id enr. interne
code révision P25
séquence de sortie relative
nom enr. externe
date création
heure création
Vue jointe de QIDCTP31/QIDCTP30
clé : Q86IRI
joint : QIDCTP31/Q31IFI -> QIDCTP30/Q30IFI
id enr. interne
id fichier interne
27
code révision P51
code révision P52
code révision P53
n° séquence relatif
Type fichier
nom fichier externe
texte descriptif
date création
heure création
Vue jointe de QIDCTP21/QIDCTP20/QIDCTP31/QIDCTP30
clé : Q88IDI
joint : QIDCTP21/Q21IRI → QIDCTP20/Q20IRI → QIDCTP31/Q31IRI
QIDCTP31/Q31IFI → QIDCTP30/Q30IFI
QIDCTP31/Q31R31 → QIDCTP30/Q30R31
id champ interne
id fichier interne
type fichier
type de fichier base de données
nom fichier externe
texte descriptif
date création
heure création
10.17 SYSINDEXES
Cette vue logique contient un enregistrement pour chaque index de la base de données.
NAME
char(10) nom de l'index
CREATOR
char(10) propriétaire de l' index
TBNAME
char(10) nom du fichier physique
TBCREATOR
char(10) propriétaire du fichier physique
TBDBNAME
char(10) nom de la librairie du fichier physique
UNIQUERULE
char(1)
clés en double autorisées
D=oui (duplicates)
U=non (unallowed)
COLCOUNT
integer
nombre de champs dans la clé
DBNAME
char(10) nom de la lbrairie contenant l'index
10.18 SYSKEYS
Cette vue logique contient un enregistrement pour chaque champs contenu dans un index.
IXNAME
IXCREATOR
COLNAME
COLNO
COLSEQ
char(10)
char(10)
char(10)
integer
integer
nom de l'index
propriétaire de l' index
nom du champs contenu dans l' index
n° d'ordre du champs dans l'enregistrement
n° d'ordre du champs dans la clé
28
ORDERING
char(1)
29
sens du tri du champs dans la clé
A=ascendant
D=descendant
10.19
10.20 SYSCOLUMNS
Cette vue logique contient un enregistrement pour chaque champs de chaque fichier logique et
physique.
NAME
char(10)
nom du champs
TBNAME
char(10)
nom du fichier contenant le champs
TBCREATO char(10)
propriétaire du fichier
R
COLNO
smallint
n° d'ordre du champs dans le fichier
COLTYPE
char(8)
type de donnée
INTEGER entier long
SMALLINT entier court
FLOAT nombre flottant
CHAR
caractère
DECIMAL décimal packé
NUMERIC décimal zoné
LENGHT
smallint
longueur ou précision
4 bytes
integer
2 "
smallint
8 "
float,float(n) n=25 à 53
ou double précision
4 bytes
float(n) n = 1 à 24, réel
longueur de la chaîne char
nombre de digits
decimal
nombre de digits
numeric
SCALE
smallint
échelle de donnée numérique (zéro si non decimal,
numeric ou non nul precision binaire)
NULLS
char(1)
N=non, Y=oui le champs peut-il contenir une valeur nulle
UPDATES
char(1)
N,Y le champs peut-il être modifié
REMARKS
char(254)
commentaires
DEFAULT
char(1)
N,Y si le champs a une valeur par défaut
LABEL
char(30)
entête de colonne
STORAGE
smallint
besoin en espace mémoire pour le stockage du champs
idem définition de lenght sauf pour decimal = (nbre digits /
2) + 1
PRECISION smallint
précision d'un champs numeric (Zéro si non numeric)
10.21 SYSTABLES
Cette vue logique contient un enregistrement pour chaque fichier physique ou logique de la
base de données.
NAME
CREATOR
TYPE
char(10)
char(10)
char(1)
nom du fichier logique ou physique
propriétaire du fichier
type de fichier
L=fichier Logique
COLCOUNT
RECLENGHT
LABEL
REMARKS
DBNAME
smallint
smallint
char(30)
char(254)
char(10)
30
P=fichier Physique
T=Table (SQL)
V=Vue (SQL)
nombre de champs du fichier
longueur des enregistrements
chaîne accessible par ordre SQL LABEL ON
commentaire
nom de la librairie contenant le fichier
10.22
31
10.23 SYSVIEWDEP
Cette vue enregistre les dépendances des vues logiques sur les fichiers physiques.
DNAME
DCREATOR
BNAME
BCREATOR
BDBNAME
BTYPE
char(10)
char(10)
char(10)
char(10)
char(10)
char( 1)
nom du fichier logique
propriétaire de la vue
nom du fichier physique
nom du propriétaire du fichier physique
nom de la librairie du fichier physique
type de l'objet sur lequel la vue porte
T=fichier physique
V=vue logique
10.24 SYSVIEWS
Cette vue contient un ou plusieurs enregistrements pour chaque vue logique de la base de
données. Chaque enregistrement contient les 70 premiers caractères de la commande de
création de la vue.
NAME
CREATOR
SEQNO
CHECK
char(10)
char(10)
integer
char(1)
TEXT
char(70)
nom du fichier logique
propriétaire de la vue
n° d'ordre d'enregistrement dans la vue le premier étant 1
inutilisé sur AS400, présent pour assurer la compatibilité
avec la norme SQL
début de l'ordre SQL de création de la vue.
32
11 Évolutions relatives au support de DB2 en V3R1M0
11.1 Support de IFS (Integrated File System)
IFS est une structure système qui permet à l'AS400 de supporter simultanément :
- un système de fichiers micro,
- un système de fichiers Unix,
- le système des bibliothèques de l'OS400,
- le système de dossiers de bureau,
- des systèmes de fichier utilisateur personnalisés.
Racine
dossiers partagés
QDLS
DB2
POSIX
QOpenSys
Unix
QSYS
QLANSrv
LAN server
QFileSrvr.400
QOPT
ToTo
QIWSFLR2
serveur
LIB
usr
Myfolder
Serv1
optique
rep1
QPWXCWN
Windows
FILE
Myrep
Home
bin
serv2
etc
Mydoc
Serv2
MEMBER
MEMBER
Serv1
serveur
rep2
optique
QPWXCRM
Rumba
fichier
fichier
QPWXCPC
5250
11.2 Réorganisation des tables système
Pour supporter le niveau 2 de DRDA, les tables système de l'OS400 ont été réorganisées.
Ainsi les tables SQL ne sont plus dans chaque collection mais dans QSYS. De plus un certain
nombre de tables supplémentaires ont été ajoutées nous trouvons maintenant :
11.3 QABDCCST
contient les informations relatives aux contraintes de niveau zone, comme nom de la zone,
position dans la clé, ...
11.4 QADBFCST
contient les informations relatives aux contraintes de niveau fichier, comme le nom de la
contrainte, le nom du fichier, ...
33
11.5 QADBIFLD
contient les informations relatives aux zones, comme type, longueur, etc ...
11.6 QADBKFLD
contient les informations relatives aux clés des chemins d'accès, comme nom de la zone, sens
du tri, ...
11.7
11.8 QADBXRDBD
contient les informations relatives au répertoire de la base de données répartie, comme les
noms des lieux éloignés, les ID d'echange de réseau, ...
11.9 QADBXREF
contenu et usage identique à la V2R3M0 ou V3R0M5.
11.10 QADBPKG
contient les informations relatives au packages SQL.
11.11 QADBFDEP
contenu et usage identique à la V2R3M0 ou V3R0M5.
D'autre part, les tables sytème SQL sont en réalité stockées dans QSYS2, leur nombre a
également augmenté.
Nom de catalogue SQL
SYSCOLUMNS
SYSCST
SYSCSTCOL
SYSCSTDEP
SYSINDEXES
SYSKEYS
SYSKEYCST
SYSPACKAGE
SYSREFCST
SYSTABLES
SYSVIEW
SYSVIEWDEP
contient les infos concernant
attributs de colonnes
toutes les contraintes
colonnes référencées dans une contrainte
dépendances des contraintes sur les tables index
index,
clés d'index
clés uniques, primaires et étrangères
packages
contraintes d'intégrité référentielle
tables et vues
définitions de vues
dépendances des vues sur les tables
11.12 Support des contraintes d'intégrité référentielle
L'intégrité référentielle permet de gérer l'intégrité de la cohérence de la base de données à
l'extérieur des programmes. C'est un progrès considérable par rapport à la base de données
version 2.3.0. Mais il y a un revers. Tout système applicatif possédant des fichiers et existant
sur l'AS400 n'est pas nécessairement normalisé. C'est à dire que souvent la base de données
applicative n'est en réalité pas une vraie base de données. C'est notamment souvent le cas dans
des applications qui ont été développées à l'origine sur un système 36.
34
Pour mettre en oeuvre l'intégrité référentielle, il est indispensable, que la base de données
satisfasse aux règles des formes normales. Si ce n'est pas le cas, mieux vaut rester en l'état.
Si, donc votre base de données est normalisée (vous avez donc utilisé MERISE pour la
concevoir), vos programmes vont se trouver alégés d'un grand nombre de lignes de code
maintenant inutiles. Avec l'intégrité référentielle, le gestionnaire de base de données peut seul
et automatiquement géré les relations entre un fichier père et un fichier fils. La règle est que
toute clé étrangère non nulle doit obligatoirement avoir son équivalent en clé primaire dans le
fichier père. Autrement dit : il ne peut exister d'enregistrement commande dont le no de client
ne serait pas une valeur d'une clé du fichier client.
La commande CL ADDPFCST permet d'ajouter une contrainte à un fichier physique, de
même que la commande SQL CREATE ALTER TABLE. Le fichier physique doit être mono
membre. Il est donc impossible de mettre une contrainte sur un fichier multi membres. La
contrainte se définie sur le fichier dépendant donc le fichier fils.
Les contrôles sont soit implicites (automatiques) en cas de création ou de mise à jour de clé
associée, soit explicites en cas de suppression. Il faut alors indiquer la règle de mise en oeuvre
au paramètre DLTRULE. Les valeurs possibles sont :
- *NOACTION
suppression d'un record dans le père interdit si au moins un
record du fils fait référence à cette clé.
- *RESTRICT
idem *noaction mais contrôle immédiat avant la suppression du
père.
- *CASCADE
lorsqu'un record du père est supprimé, tous les records du fils
contenant la même valeur de clé sont supprimés.
- *SETNULL
lorsqu'un record du père est supprimé, tous les records du fils
sont mis à jour avec la valeur nulle à condition que cette valeur soit admise dans la description
du fils.
- *SETDEFAULT idem *SETNULL mais c'est la valeur par défaut définie dans le
fils qui est utilisée.
La différence entre *NOACTION et *RESTRICT est subtile mais importante. Si vous utilisez
*NOACTION la journalisation est obligatoire. En effet toutes les mises à jour et suppressions
seront effectuées avant que la contrainte soit lancée. Au cas ou un message d'erreur survient
(le message ESCAPE est le moyen de communication entre le SGBD et votre programme)
vous devez invalider les mises à jour. Or sans la possibilité du ROLLBACK c'est une
opération périlleuse. Si par contre vous utilisez *RESTRICT, la vérification est lancée avant
les mises à jour et le message intervient dans votre programme RPG sans que vous ayez à
faire une mise à jour arrière.
*RESTRICT donne donc de meilleures performances et doit être préféré à *NOACTION qui
est pourtant la valeur par défaut du paramètre.
11.13 Support des triggers ou déclencheurs
35
Sur AS400 le déclencheur et le programme déclenché s'appellent tous deux trigger, d'où une
confusion possible. Un trigger est un call automatique d'un programme écrit dans n'importe
quel langage disponible sur l'AS400 et dont le contenu et l'action est entièrement laissé à la
discrétion du programmeur. il y a également des règles (rules) pour l'ajout, la mise à jour ou la
suppression d'enregistrement (les triggers de zone ne sont pour l'instant pas disponibles sur
AS400).
Généralement un trigger de record est utilisé pour faire les contrôles de zones du record. Ainsi
vos programmes se trouvent déchargés du contrôle des zones qui est laissé à la charge du
SGBD. Ici encore le moyen de communication entre votre programme RPG et le SGBD est le
message de type *ESCAPE.
La commande ADDPFTRG permet d'ajouter un trigger à un fichier physique. Le SQL de
l'AS400 ne supporte pas pour le moment et ce au moins jusqu'en 1996 d'ordre pour les triggers
et ce en attente d'une normalisation devant être effective avec la norme SQL3.
Néanmoins la fonction trigger est très riche et permet de définir pour un seul record un trigger
avant et après création, mise à jour et suppression. Six triggers différents peuvent donc être
déclenchés pour un même record.
Le programme déclenché a obligatoirement deux paramètres d'entrée qui sont une structure et
la longueur de la structure.Le dessin de la structure est :
- nom du fichier (fichier, bibliothèque, membre)
- type d'opération (création, mise à jour, suppression)
- moment de l'appel (avant, après)
- niveau de verrouillage
- pointeur position et longueur (dans la structure) du buffer avant l'opération
- pointeur position et longueur (dans la structure) du buffer après l'opération
- valeurs du buffer avant
- valeurs du buffer après
un exemple de description de structure est disponible dans le membre
LIBUXX/XXX,XXXCITRG en RPGIII et dans LIBUXX/XXXX, XXXXCITRG pour RPG
IV.
11.14
11.15 Les messages escape du SGBD
En cas de violation de l'intégrité référentielle, les messages suivants sont émis :
- CPF502D violation de CIR sur le membre &4 en ajout dans un fichier fils sans
correspodance dans le fichier père.
- CPF503A violation de CIR sur le membre &4 en suppression du fichier père alors
qu'il existe des records du fichier fils faisant référence à cette valeur de clé étrangère.
- CPF502E enregistrement verrouillé, la CIR ne peut être lancée.
- CPF523B erreur de CIR lors du traitement du membre &4 impossibilité système.
36
- CPF523C erreur dans le journal d'intégrité référentielle. les règles demandent un
contrôle de validation, mais la journalisation n'est pas démarrée ou les récepteurs de journaux
des deux fichiers sont différents.
De plus RPGIV ILE envoie les messages suivants :
- RNQ1022 (*inquiry) et RNX1022 (*escape) correspondant aux messages CPF502D
et CPF503A.
- RNQ1299 (*inquiry) et RNX1299 (*escape) correspondant aux messages CPF523C
et CPF523B.
Il est donc capital de savoir gérer les messages escape en RPG grâce aux APIs de messages.
11.16
11.17
11.18 Procédures cataloguées
Une implémentation de SQL pour mise à niveau avec SQL2 permet à DB2/400 de mettre en
oeuvre les procédures cataloguées. La syntaxe SQL est :
EXEC SQL
DECLARE nomdeprogramme PROCEDURE (:parm1 IN CHAR(10) :parm2 IN DECIMAL
(5,2))
EXTERNAL NAME nomlib/nomde programme
LANGUAGE RPG
END-EXEC.
EXEC SQL
CALL nomdeprogramme (:parm1, :parm2)
END-EXEC.
Il est ainsi possible d'appeler dans le SQL un programme écrit dans n'importe quel langage
disponible sur l'AS400 avec passage de paramètres.
11.19 Validation à deux phases ou two phases commit
DB2/400 supporte le niveau 2 de DRDA et assure automatiquement la gestion des commit et
roll back sur des bases de données réparties même en cas de rupture du réseau.
37
12 Les fichiers de l'OS400
12.1
12.2 Types de fichiers
L'OS400 supporte 4 types de fichiers.
- fichiers de données (physiques ou logiques) PF LF,
- fichiers écrans DSPF,
- fichiers imprimantes PRTF,
- fichiers de communications ICFF.
Attention : seuls les PF contiennent des datas, les LF contiennent les clés de recherche et les
DSPF, PRTF, ICFF ne contiennent que des descriptions.
Fichier PF comportant les données.
Contient 3 parties :
Fichier LF : Logical File
Fichier BD dépendant d'un PF ou de plusieurs PF (max. 32) et servant à créer :
- un index sur les données du PF : un chemin d'accès aux données du PF.
- un classement des données du PF : un tri pour une lecture séquentielle.
- une sélection des données du PF : une vue sélective des données.
- un regroupement de données de plusieurs PF dans un même fichier : logique joint.
Contient 2 parties :
( pas de données dans un LF )
38
PF
LF
Puisque manipulés par l'OS400 les fichiers sont des objets. En tant que tels ils doivent avoir
une description, contenue dans un membre source d'un fichier source. Cette description doit
ensuite être compilée soit par l'option 14 de PDM, soit par la commande CRTxF (x étant le
type de fichier) pour que le fichier existe sur le disque.
Au niveau du système, il existe en réalité plusieurs objets qui ne sont vus par l'utilisateur que
comme un objet unique se sont :
- les data spaces qui contiennent les datas, les enregistrements base de données. C'est
que que nous pouvons appeler les membres. Cette définition nous permet de
comprendre qu'un membre se comporte au moment des accès comme un fichier à part
entière avec ouverture, début, fin, fermeture. C'est la commande OVRDBF qui permet
d'accéder aux différents membres donc aux différents data spaces du même fichier.
dans un data space les enregistrements sont rangés par ordre d'arrivée.
- les index de data space qui permettent d'ordonner les enregistrements de data space
autrement que dans l'ordre d'arrivée. Le mécanisme d'ordonnancement des
enregistrements est basé sur un algorithme d'arborescence dichotomique basale. C'est
ce qu'on appelle en OS400 les chemins d'accès.
- les curseurs sont des mécanismes de visualisation des données. Ils contiennent les
mécanismes de sélection et d'omission. C'est ce qui sert de base à la fonction
OPNQRYF de l'OS400 ou à l'ouverture avec sélection dynamique. Il est possible dans
ces curseurs de réaliser des fonctions de mapping qui permettent de voir les données
sous d'autres formats que ceux stockés ou de créer des zones résultantes d'opérations
sur des zones existantes. Les ordres OPEN et CLOSE couramment utilisés en HLL
déclenchent les instructions MI ACTIVATE CURSOR et DEACTIVATE CURSOR
12.3 Accès aux fichiers
L'OS400 considère tous ses périphériques (devices) comme des périphériques "bloc". C'est à
dire qu'il ne converse avec eux que par paquets d'octets et non octet par octet. Ainsi sur un
39
écran par exemple il n'est pas possible d'adresser directement une ligne colonne et d'y inscrire
un caractère.
On ne pourra écrire ou lire sur l'écran que la totalité de cet écran. De même dans un fichier de
données, on ne pourra accéder qu'à un enregistrement et pas à un caractère unique. L'accès
physique dépend avant tout de la capacité d'entrée sortie de chaque appareil.
Dans la réalité, un lecteur de diskette pourra lire ou écrire 128, 256, 512 octets à la fois. Un
lecteur de disque dur pourra accéder à 512, 1024, 2048, 4096 octets à la fois. Un contrôleur
d'écran pourra gérer 1920 ou 2000 octets à la fois.
Les lectures et écritures se feront par block du nombre d'octets gérables par l'appareil
considéré.
Pourtant il arrive souvent qu'on ne désire pas accéder à un nombre aussi important d'octets. Il
y a donc un accès logique pour l'utilisateur qui est différent de l'accès physique de la machine.
Il faut donc utiliser un intermédiaire qui permettra le découpage logique des données
physiquement présentes.
Cet intermédiaire est appelé un tampon (buffer). Les données en entrée ou en sortie seront
stockées dans ce buffer en attendant que le block soit complet pour être effectivement échangé
avec l'appareil. Le terme de buffer est employé au niveau physique et au niveau logique. Par
exemple, la taille du buffer physique du disque peut être de 4096 octets et la taille du buffer
logique du fichier à traiter peut être de 128 octets.
Lorsque l'on désirera lire un enregistrement de 128 octets, on accédera en réalité à 32
enregistrements de ce fichier sur le disque. Si on réécrit le premier enregistrement lu, il n'y
aura pas d'écriture physique sur le disque mais seulement dans le buffer physique. Ce qui est
beaucoup plus rapide car ce sont seulement des transferts en mémoire. Si la lecture suivante
fait appel à un des 31 autres enregistrements contenus dans le buffer physique, il n' y aura pas
d'accès disque en lecture.
Il n'y aura que transfert mémoire de l'enregistrement contenu dans le buffer physi que dans le
buffer logique. Par contre si le 2 ème enregistrement demandé n'est pas dans les 31
disponibles, il y aura d' abord écriture du buffer physique sur le disque puis lecture d'un autre
groupe de 32 enregistrements.
Il faut donc décrire au système la taille du buffer logique du fichier que l'on désire utiliser,
pour permettre les accès. Sur AS400 cette opération s'appelle DDS (data description
specification). Les descriptions de fichiers seront entrées dans des spécifications sources de
type A dont vous pouvez voir un exemple en annexes.
12.4 CONTRÔLE DES ACCÈS FICHIERS
D'une façon générale le contrôle des accès aux fichiers est laissé à la charge du système
d'exploitation. Celui-ci ne communiquant aux programmes qui désirent accéder à ces fichiers
que des codes retour renseignant sur l'issue de la dernière opération effectuée (opération
40
réussie ou non et si non pour quel motif. L'OS/400 donne au programmeur la possibilité
d'accéder à de nombreuses informations sur les fichiers accèdés.
Deux zones de contrôle fichier sont disponibles, après une opération réussie d'ouverture sur un
fichier. Il s'agit de l' open feedback area et de l'I/O feedback area. Ces zones de contrôle
peuvent se révéler très utiles lorsqu' une erreur se produit sur un fichier.
12.4.1 Open feedback area
Cette zone contient des informations d'ordre général sur le fichier comme son nom, la
librairie, le type etc ...
12.4.2 I/O feedback area
Cette zone est découpée en deux parties. La première commune à tous les types de fichiers
d'une longueur de 143 octets et donnant des renseignements comme des compteurs
d'opérations d'entrée sortie par type d'opération, la nature de l'opération en cours, le nom du
format d'enregistrement en cours, le type de périphérique utilisé, etc ... La deuxième étant en
fonction du type de fichier. Une description détaillée des différentes I/O feedback est donnée
dans des membres de LIBUXX/YYY,YYYMIxF (x =G[LF],.=D[DSPF], =P[PRTF]).
41
13 Les fichiers de données
13.1 Structure
La structure des fichiers de données peut être shématisée selon l'exemple suivant :
14 Description
Une description de spécifications de données est enregistrée dans un fichier source.
Les zones décrites dans une DDS sont les plus petits éléments physiques et logiques
accessibles par l'OS400. Il n'est pas possible d'appliquer un tampon logique différent du
tampon physique sur une zone de la base de données AS400. Un découpage logique d'une
zone de la base de données ne sera possible qu'à l'intérieur d'un programme par l'intermédiaire
d'une structure de données.
La description externe des fichiers, garantie l'indépendance des données et des programmes.
En effet la description est identique quelque soit le langage utilisé dans les programmes.
Il existe 4 niveaux logiques de description des fichiers :
- niveau fichier
(file),
- niveau format ou enregistrement (record),
- niveau zone ou champs
(field),
- niveau clé
(key),
Pour chaque niveau il existe des mots clé spécifiques qui permettent d'apporter des précisions
sur la description.
14.1 fichiers physiques
Le fichier physique de données est le type d'objet OS400 qui contient effectivement les
données utilisateurs. Nous verrons un peu plus loin que les fichiers logiques ne contiendrons
que les chemins d'accès à ces données de fichiers physiques.
42
14.2 Structure
Un fichier physique de données est constitué :
- D'un format qui est la version compilée de la description de fichier.
- D'un chemin d'accès qui est la façon d'accéder aux enregistrements du fichier.
Le chemin d'accès peut être par ordre d'arrivée c'est à dire sans organisation particulière autre
que le n° relatif d'enregistrement par rapport à l'ordre dans lequel les enregistrements ont été
écrits sur le disque. C'est la forme qui est recommandée.
Il peut être par index si une ou plusieurs zones de la description d'enregistrement ont été
renseignées comme clé (K). Dans ce cas le chemin d'accès existe physiquement et est organisé
sous forme d'arbre binaire afin d'en faciliter le traitement. Cette forme n'est pas recommandée
car elle offre peut de sécurité contre une destruction du fichier par maladresse.
- Des données regroupées éventuellement par membres distincts. L'accès par défaut
étant sur le 1 er membre. Pour accéder à un autre membre, il sera nécessaire de recourir à la
commande
OVRDBF
43
15 Mots clé
15.1 Niveau fichier
ALTSEQ
Définition : ALTSEQ (nom bibliothèque/nom table)
nom bibliothèque EST OPTIONNEL
Il classe les enregistrements en utilisant une table de remplacement contenant une séquence de
classement pour la clé. Autrement dit, le fichier peut être trié sur la clé, si ALTSEQ est
mentionné et qu'une séquence de classement est spécifiée pour la clé. Pour cela, il utilise une
table.
FIFO
(premier entré, premier sorti)
On utilise ce mot clé pour préciser l'ordre de sortie des enregistrements d'un fichier physique,
l'ordre est le premier entré, premier sorti.
Ce mot clé n'a pas de paramètre.
On ne peut pas l'utiliser avec les mots clé LIFO, UNIQUE et REAFACCPTH.
Si ni FIFO, ni LIFO ou ni UNIQUE ne sont spécifiés, les enregistrements seront sortis soit
dans l'ordre premier entré, premier sorti ou dernier entré premier sorti.
Au moins une clé de champ doit être spécifiée dans le fichier qui contient le mot clé FIFO.
FIFO n'est pas valide si l'on précise un type de fichier *CSRC sur une commande de création
de fichier logique.
LIFO
On utilise ce mot clé pour préciser que les enregistrements récupérés dans un membre de
fichier physique sont dans l'ordre :
DERNIER-ENTRE / PREMIER-SORTI
Ce mot clé n'a pas de parametres.
On ne peut l'utiliser avec les mots clé suivants : FIFO ,UNIQUE et REFACCEPTH.
Si,ni LIFO,FIFO et UNIQUE ne sont spécifiés,les enregistrements sont récupérés soit dans
l'ordre: PREMIER-ENTRE / PREMIER-SORTI, soit DERNIER-ENTRE / PREMIERSORTI. Mais l'ordre dans lequel on récupère les enregistrements n'est pas garanti.
Au moins un champ clé doit être précisé dans le fichier qui contient le mot clé
LIFO. Ce mot clé n'est pas valide lorsque l'on précise un type de fichier (*SRC) sur la
commande de création d'un fichier logique.
44
REFSHIFT
Mot clé de niveau fichier utilisé pour contrôler l'accès de saisie dans les champs.
Ex : REFSHIFT(X)
Accepte les lettres de A à Z plus , . - espace transforme tout en majuscules.
Il y a 8 valeurs possibles associées à REFFLD qui sont :
- X, A, N, S, Y, W, I, D, M et F.
Voir aussi Data type/keyboard shift page 4-11 du DDS reference.
REF
Mot clé de niveau fichier utilisé pour préciser le nom du fichier duquel les descriptions sont
tirées.
Son format est :
REF( Biblio./Fichier de données (nom du format d'enregistremt))
Pour préciser plusieurs fichiers-origine il faut utiliser le mot-clé REFFLD.
Pour plus d'infos sur REF et REFFLD, voir : Appendix A, "When to specify REF and
REFFLD" DDS reference.
************** Début des données ************************
0001.00 A
REF(ALXREP)
0002.00
A
R ARTENR
0003.00
A
ARTCOD
R
0004.00
A
ARTDES
R
0005.00 A
ARTFRN
R
REFFLD(FRNDCO)
0006.00
A
ARTQST
R
0007.00
A
ARTQMT
R
0008.00
A
ARTPRU
R
0009.00 A
ARTTVA
R
*************** Fin des données *************************
UNIQUE
Ce mot clé n'a pas de paramètres.
On utilise ce mot clé pour spécifier que des enregistrements différents avec des valeurs de clé
identiques ne sont pas autorisés dans un membre du fichier physique.
Aucune addition ou mise à jour dans une clé en double n'est acceptée. Le programme
d'application faisant l'écriture ou l'opération de mise à jour reçoit un message d'erreur, de
même qu'un programme DFU. Une commande de copie de fichier qui copierait des
enregistrements avec des clés en double dans le fichier ne serait pas valide.
Quand un fichier logique rattaché à ce fichier physique, a le mot clé UNIQUE, le ou les
membres du fichier physique ne peuvent pas avoir de clés en double. Quand on précise le mot
clé UNIQUE pour un fichier physique, on doit préciser la valeur de paramètre MAINT
(*IMMED) sur la commande de création de fichier (CRTPF) pour créer le fichier. Cela
signifie que le chemin d'accès est mis à jour immédiatement au fur et à mesure des
changements.
45
Quand le mot clé UNIQUE n'est pas précisé, les enregistrements avec des valeurs de clés en
double sont rangés soit dans l'ordre premier entré - premier sorti, soit dernier entré - premier
sorti.
Si on ne précise pas le mot clé UNIQUE, ni FIFO, ni LIFO, par défaut les enregistrements
seront traités en FIFO.
Le mot clé UNIQUE ne peut pas être utilisé en même temps que FIFO, LIFO, ou
REFACCEPTH.
FMT LF
A..........T.Name++++++.Len++TDpB
Functions++++++++
************** Début des données **************************
0001.00
A
UNIQUE
0002.00
A
R ARTENR
PFILE(ARTP)
0003.00
A
K ARTCOD
*************** Fin des données ***************************
15.2 Niveau format d'enregistrement
FORMAT
Le mot clé FORMAT sert à réutiliser dans un autre fichier ( exemple fichier n°2) des champs
identiques, au fichier d'origine ( exemple fichier n°1 ).
On utilise ce mot clé de niveau format pour préciser que ce format aura les mêmes
spécifications de champs, qu'un niveau format précédemment défini.
La syntaxe est la suivante :
FORMAT (!LIBRARY-NAME/! PHYSICAL-FILE-NAME)
Les points d'exclamations signifient que le nom de la librairie est optionnel.
Si l'on ne spécifie pas le nom de la librairie, la liste des librairies (*LIBL) active au moment
de la création, est utilisée.
Certaines restrictions existent quand à l'utilisation du mot clé FORMAT :
- Ne pas spécifier les spécifications des champs, pour ce niveau de format. Spécifier
les spécifications des clés, si vous voulez quelles soient actives pour ce fichier ( elles peuvent
être les mêmes ou bien différentes, que le niveau de format précédemment défini).
- On ne peut spécifier un fichier DDM ( Distributed Data Management ) sur ce mot
clé.
- Un fichier logique n'est pas autorisé pour le mot clé FORMAT.
- Si le fichier physique contenant le format d'enregistrement que vous utilisez est
supprimé, le niveau de format reste existant, aussi longtemps que le format d'enregistrement
est utilisé dans un fichier quelconque.
Par exemple, RECORD dans le fichier 2 utilise le mot clé FORMAT pour partager les
spécifications du RECORD dans le fichier 1. Les deux fichiers ont été créés. Si le fichier 1 est
46
supprimé, puis recréé avec différents DDS ( Data Description Specification ), RECORD reste
existant dans le fichier 2.
Il peut être référencé à partir du niveau de format originel, par d'autres fichiers utilisant le mot
clé FORMAT.
47
15.3 Niveau zone
ALIAS
format : alias(nom de remplacement)
Ce mot clé alias est utilisé afin de donner un nom de remplacement à la zone correspondante
d'une longueur supérieure à 6 ; comprise entre 1 et 30 et commençant obligatoirement par une
lettre. Les caractères suivant peuvent être soit des chiffres, soit des lettres soit le trait
bas(_)(très utilisé pour les applications développées en COBOL). L'alias est directement
transcrit dans le programme lors de la compilation à la place du nom de champ (pos:19/28).
Un alias doit obligatoirement être différent d'un autre, ainsi que d'un nom de champ défini
dans la DDS, dans le cas contraire un message d'erreur est signalé.
L'alias ne peut être utilisé comme un nom de champ(DDS), comme clé d'un nom de champ ou
comme un nom de champ dans une commande (ex:CPYF).
ALWNULL
Ce mot clé permet l'autorisation de valeurs nulles pour le champ auquel il faut référence.
Lorsque ce mot clé est indiqué, la longueur du champ en vis à vis ne doit pas dépasser 32765
caractères.
CHECK
Ce mot clé attribue un contrôle de validité au niveau du CHAMP dans un fichier écran. Il
n'intervient pas directement dans les fichiers physiques.
Les codes utilisés pour 'CHECK' sont :
- CHECK AB (allow blank) :zone à blanc autorisée,
- CHECK ME (mandatory enter):frappe obligatoire,
- CHECK MF (mandatory fill) :zone complète si frappée,
- CHECK M10
:contrôle modulo 10,
- CHECK M11
:contrôle modulo 11,
- CHECK VN (valid name) :contenu zone doit être un nom valide,
- CHECK VNE(valid name extend).
Le contrôle se fait par un chiffre de contrôle permettant de vérifier la validité des données. Ce
chiffre est le résultat d'un calcul effectué sur les autres chiffres.
Vous ne pouvez pas utiliser CHECK AB, VN, VNE, M10, M11 pour un champ défini en
virgule flottante.
CMP
Ce mot clé est équivalent au mot clé COMP
48
Le format est :
CMP(opérateur relationnel, valeur)
Le mot clé COMP est préféré - Voir la description du mot clé COMP(comparaison ) pour une
explication sur l'utilisation de ce mot clé.
COMP
Utilisez ce mot-clé de niveau champ pour spécifier la vérification de validité, aux champs que
vous définissez lorsqu'il sera référencé ultérieurement lors de la création d'un fichier écran ou
à la création d'applications DFU.
La syntaxe est:
COMP(opérateur relationnel- valeur)
Quand l'on définit dans un fichier écran un champ au type zone en entrée (input) référencez le
champ que vous êtes en train de définir par la lettre R dans la position 29 ou le mot-clé de
REF OU REFFLD.
OS/400 copie le mot-clé COMP et les attributs du champ dans le fichier physique
vers le champ du fichier écran. Vous pouvez substituer les mot-clé de type contrôle de
validité (validity-checking) en les spécifiant pour le champ dans le fichier écran. (voir
"référencer, position 29" dans la page 4-9.
Il ne faut pas spécifier le mot clé dans un champ de type flottant "F dans la position 35.
Les régles pour spécifier ce mot-clé dans un fichier physique sont les mêmes que pour un
fichier écran.
"voir COMP (comparaison) à la page 4-75 pour pour connaître les informations de Note:
COMP est équivalant de CMP
COLHDG
Le format est :
COLHDG('ligne -1'('ligne -2' ('ligne -3')))
Un maximum 3 lignes de 20 caractères chacune est autorisé.
FMT PF
A..........T.Name++++++
************** Début des données
0001.00
A
R REPENR
0002.00
A*
0003.00
A* Client
0004.00
A
CLINBR
0005.00
A
0006.00
A
CLIRAI
0007.00
A
0008.00
A
CLIRUE
0009.00
A
RLen++TDpB Functions+++++++++++++++
*********************************
5 0
40
40
TEXT('Code client . . .
COLHDG('N°CLI.')
TEXT('Nom du client . .
COLHDG('NOM DU CLIENT')
TEXT('N° et rue . . . .
COLHDG('N° ET RUE')
0010.00
A
CLICMP
49
40
TEXT('Complément d''adresse')
Utilisez ce mot clé de niveau champ afin de spécifier l'entête de colonne utilisée pour ce
champ pour la gestion de texte, l'utilitaire QUERY, l'utilitaire de fichiers de données (DFU) et
l'utilitaire d'aide de conception d'écran (SDA).
Chaque ligne d'entête de colonne doit être entourée d'apostrophes .Utilisez l'apostrophe double
pour spécifier l'apostrophe à l'intérieur d'une entête de colonne.
Si vous ne spécifiez pas COLHDG et que le champ référencé n'est pas récupéré d'un champ
référencé, le nom du champ est utilisé.
Si vous spécifiez COLHDG et ne spécifiez pas texte, 50 positions d'information d'entête de
colonne sont utilisables en tant que texte. Par exemple TEXTE ('ORDER DATE') est construit
par OS/400 quand ((when the field spécifies COLHDG ('order''date') but no text keyword)
montre comment spécifier le mot clé COLHDG. L'exemple suivant montre comment apparaît
le texte du mot clé lorsqu'il est géré par text managment, query, dfu, ou SDA.
ORDER
DATE
NNNN
CUSTOMER
CITY
CUSTOMER'S NAME
FIELD
XXXXXXXXXXXXXXXXXX
XXXXXXXXXXXX
CSSID
Ce mot clé est utilisé au niveau zone, mais peu aussi être aussi utilisé au niveau record ou
fichier.
Au niveau zone il est utilisé pour une zone déclarée en type G « graphique » pour préciser que
ce champ est de type UCS-2 (unicode).
Le format est :
CSSID(UCS2-numéro)
Numéro est une valeur comprise entre X’7200’ et X’72FF’ et est un numéro valide de CSSID.
DATFMT
Ce mot clé est utilisé pour indiqué le format de date d'un champ de type date.
Le format est :
DATFMT(format de date)
Les formats de date possibles sont:
- *JOB,
- *MDY,
- *YMD,
- *DMY,
- *JUL,
- *ISO,
- *USA,
- *EUR,
- *JIS.
Si ce mot clé n'est pas indiqué le format par défaut est *ISO.
50
DFT
Utiliser le mot clé niveau zone DFT pour spécifier une valeur par défaut pour un champ.
Le format est :
DFT('valeur') ou (X 'valeur')
où X = 'valeur hexadécimale'
Les valeurs constantes peuvent être :
Une valeur caractère dans laquelle chaque caractère est imprimé selon la spécification. Le
nombre de caractères est égale à la longueur imprimée du champ. Une valeur hexadécimale,
dans laquelle deux caractères identifient un code dans le jeux de caractères. Ces caractères
s'impriment dans ce champ.
Les indicateurs ne sont pas valides pour ce mot clé. Cependant ils peuvent être utilisés pour
conditionner le champ constant avec lequel ce mot clé est spécifié, en précisant l'indicateur sur
la même ligne où le champ est spécifié.(voir doc DDS Référence 5-48).
Quand l'indicateur concerné est actif (ON), le champ constant correspondant s'imprime avec
les quotes.
Le mot clé Transparency (TRNSPY) est requis lorsqu'une valeur hexadécimale est spécifiée
pour le mot clé DFT.
EDTCDE et EDTWRD
Ces mots clé sont utilisés pour indiquer comment se fera l'affichage ou l'impression de la zone
en vis à vis. Celle-ci est une zone numérique. Ce mot clé n'a pas de répercussion directe pour
le fichier physique.
0000.40
0000.50
0000.60
0000.70
A
A*
A
A
0013.70
A
0014.30
0014.40
A
A
R ECR010
1 2DATE
EDTCDE(Y)
QMTART
5Y 0B 8 27EDTCDE(Z)
PRUART
9 2'Prix unitaire H.T. . . .'
7Y 2B 9 27EDTWRD(' , ')
FLTPCN
VIRGULE FLOTTANTE
Ce mot clé de niveau champ spécifie la précision de la virgule flottante pour une zone
numérique.
Le format est:
FLTPCN(*single/*double)
Le paramètre indique si la zone est en simple ou double précision. Ce mot-clé est seulement
valide pour un champ en virgule flottante.
51
Le mot clé est par défaut en simple précision. Dans un champs en simple précision on peut
avoir jusqu'à 9 positions maximum et en double précision on peut avoir jusqu'à 17 positions
maximum.
Si le champs spécifié dépasse la longueur maximale, un message d'erreur s'affichera et le
fichier ne sera pas créé.
RANGE
Le format est:
RANGE (Valeur-minimale Valeur-maximale)
Utilisez ce mot-clé de niveau champ pour spécifier un contrôle de validité sur la zone que
vous définissez lorsqu'elle sera référencée pendant la création d'un fichier écran ou la création
d'une application DFU.
RANGE ne modifie pas le fichier physique que vous avez défini.
Quand vous définissez une zone d'entrée dans un fichier écran, référencez la zone en
spécifiant la lettre R en position 29 et le mot-clé REF ou REFFLD. L'OS400 copie le mot-clé
RANGE et les autres attributs de zone à partir de la zone du fichier physique dans la zone du
fichier écran. Vous pouvez modifier les mots-clé de contrôle de validité en les spécifiant pour
la zone dans le fichier écran. Les données entrées doivent être supérieures ou égales à la
valeur minimale et inférieures ou égales à la valeur maximale. Quand la zone est de type
caractère, les valeurs du paramètre doivent être entre apostrophes. Quand la zone est
numérique, les apostrophes ne doivent pas être spécifiées.
Les indicateurs d'option ne sont pas valides pour ce mot-clé. La donnée entrée dans une zone
numérique est alignée sur le nombre de décimales spécifiées en colonnes 36 à 37, les blancs
de début et/ou de fin sont remplis avec des zéros. Ne pas spécifier le mot-clé RANGE pour
une zone en virgule flottante (F en position 35).
Les règles pour spécifier ce mot-clé dans un fichier physique sont les mêmes que pour un
fichier écran.
Voir RANGE à la page 4-182 pour plus d'informations, ainsi que pour un exemple montrant
comment spécifier ce mot-clé.
REFFLD
Le format est :
REFFLD ((nom du format d'enregistrement/)nom du champ référencé
((*SRC ou biblio/fichier de données)))
Mot clé de niveau fichier utilsé pour réferencer un champ sous 3 conditions :
- quand le nom du champ réferencé est different du nom se trouvant dans les positions
entre 19 et 28,
52
- quand le nom du champ réferencé est le meme que celui se trouvant dans les
positions entre 19 et 28 mais que le format d'enregistrement, le fichier ou la bibliothèque du
champ référencé est different de celui précisé avec REF,
- quand le champ réferencé se trouve dans le même fichier source DDS que le champ
de référence.
TEXT
Le format est :
TEXT('description')
On utilise ce mot clé au niveau enregistrement ou au niveau champ pour effectuer une
description de texte.
La description doit être entre apostrophes, avec un maximum de 50 caractères.
Au cas ou plus de 50 caractères sont spécifiés, le mot clé est accepté. Toutefois, les caractères
supplémentaires ne sont pas pris en compte.
Si TEXT n'est pas spécifié et que le mot clé COLHDG est précisé, 50 positions sont utilisées
par défaut. Si l'on ne précise pas COLDHG et que le champ n'est pas concaténé, le texte est
pris dans le champ physique TEXT s'il existe. Si l'on ne précise pas COLDHG et que le
champ est concaténé, Il n'y a pas de texte.
NB : L'on peut préciser TEXT aussi bien au niveau enregistrement qu'au niveau champ.
On peut préciser a la fois TEXT et FORMAT au niveau enregistrement car l'enregistrement
contient toujours du texte.
VALUES
Le format est:
VALUES(VALUE1{VALUE-2----{VALUE-100}})
Sa destination est de valider la vérification du champ que vous avez défini quand il est
référencé plus tard lors de la création du fichier écran ou après la création d'une application
dans DFU.
VALUES n'affecte pas le fichier physique que vous avez défini. Mais quand vous définissez
un champ de saisie dans un fichier écran vous pouvez référencer le champ que vous avez
défini (en spécifiant R en position 29 et REF ou REFFLD mot clé). Pendant la création du
fichier écran l'OS400 copie les valeurs du mot clé et les attributs du champ du fichier physique
dans le champ qui est dans le fichier écran.
Vous pouvez substituer, vérifier, valider ce mot clé en le spécifiant pour le champ dans le
fichier écran. Voir "REF (réference) page 4-183 pour plus de détails".
Vous ne pouvez pas spécifier le mot clé values dans un champ décimal là ou il y a une virgule
flottante (il faut mettre F dans la colonne 35) les règles de spécification du mot clé VALUES
dans un fichier physique sont les mêmes que pour le fichier écran.
53
15.4 Niveau clé
Les mots clés possibles sont identiques entre fichiers physiques et logiques.
16 fichiers logiques
Un fichier logique est un objet OS400 qui contient des chemin d'accès par clé d'index aux
données d'un ou plusieurs fichiers physiques. Pour sécuriser les données tout chemin d'accès
au données doit être réalisé sous la forme d'un fichier logique.
En effet tant qu'il existe au moins une relation entre un fichier logique et sa base physique, la
base physique que constitue le fichier physique est indestructible par une commande système.
A l'inverse lorsque l'on désire supprimer un fichier physique, il faut s'assurer par la commande
DSPDBR (Display Data Base Relations). Qu'aucun fichier logique n'est plus basé sur le
physique à détruire.
16.1 Structure
Un fichier logique comprend, comme un fichier physique, une description de format et un
chemin d'accès mais il ne contient pas de membre de données. Ces dernières sont uniquement
dans le fichier physique.
Le format d'enregistrement d'un fichier logique sert essentiellement à décrire les clés d'index
servant à accéder aux données.
Mais il peut servir également à décrire un format d'enregistrement différent du fichier
physique ne laissant apparaître que certaines zones du physique. Il s'agit alors d'une vue
logique à ne pas confondre avec une vue SQL.
16.2 Logiques joints
Il est possible de créer un fichier logique qui soit basé sur plusieurs physiques et de créer un
format d'enregistrement purement logique qui donne accès à diverses zones de plusieurs
physiques étant vues alors par les programmes d'application comme un seul fichier. Un tel
fichier est appelé un fichier joint.
Pour créer un logique joint il faut prendre un fichier dit "de base" qui servira de référence pour
effectuer les lectures principales. Il doit exister ensuite dans chaque paire de fichiers une zone
dont une valeur soient commune aux deux fichiers. En général ce sera une zone ayant la
même signification. Les lectures de fichier en fichier se feront automatiquement.
Un fichier logique joint ne peut être utilisé qu'en lecture uniquement. Une tentative de mise à
jour pourrait provoquer des résultats inattendus.
Les zones de joint des fichiers logiques joints devront être codifiées avec un soin tout
particulier. Il sera préférable que les noms de zones soient tous différents pour éviter les
54
quiproquo au programmeur et au système. L'usage du mot clé de niveau zone REFFLD est
particulièrement recommandé pour définir les zones de jointures.
55
16.3 Conversions de type de données
Il est possible de convertir le sous type d'une donnée numérique entre le fichier physique et le
fichier logique. Pour plus d'informations sur ce sujet consultez la brochure IBM AS400 DDS
reference SC-41-9620 chapitre 2.
17 Mots clé
Comme pour les fichiers physique il existe des mots clé pour chaque niveau du fichier.
17.1 Niveau fichier
DYNSLT
Ce mot clé vous permet d'indiquer que la sélection/omission d'enregistrements s'effectuera
conformément aux instructions de niveau sélection/omission dynamiquement pendant le
traitement du fichier.
Ce qui veut dire que à chaque lecture du fichier le système testera si il doit fournir au
programme l'enregistrement lu ou si il doit passer automatiquement au suivant.
Cette façon de procéder peut ralentir quelque peu le système, mais est parfois beaucoup plus
rentable que la mise à jour de chemins d'accès particuliers. Ce genre de fichier logique, dans le
cas ou le nombre d'enregistrements sélectionnés représente un pourcentage important par
rapport à l'ensemble du fichier peut être beaucoup plus rapide et rentable en charge CPU qu'un
OPNQRYF.
Il n'est pas possible d'utiliser DYNSLT avec REFACCPTH.
FCFO
Ce mot clé permet d'indiquer pour les clés dupliquées que la première fournie sera la clé
modifiée en premier.
JDFTVAL
Ce mot clé doit être utilisé pour indiquer au système qu'il doit prendre des valeurs par défaut
pour les joints secondaires où il ne trouverait pas de correspondance de valeur.
Si ce mot clé n'est pas indiqué, le système ne délivrera pas un enregistrement si tous les joints
indiqués ne sont pas satisfaits.
Les valeurs par défaut peuvent être modifiées par l'emploi du mot clé DFT.
56
17.2 Niveau enregistrement
PFILE
Ce mot clé sert à indiquer sur quel fichier physique est basé le fichier logique.
Ce mot clé peut contenir plusieurs valeurs. Dans ce cas il s'exclue avec le mot clé JFILE. Le
maximum de fichiers physiques indiqués est de 32.
L'usage de ce mot clé avec plusieurs valeurs est réservé aux fichiers logiques basés sur
plusieurs fichiers physiques de structure identique. Si d'aventure une zone ne figurait pas dans
tous les formats d'enregistrement de tous les fichiers physiques décrits, elle ne pourrait pas
être indiquée dans le format du fichier logique.
JFILE
L'usage de ce mot clé est identique à PFILE mais sans les restrictions de zones et est donc
spécialement conçu pour les fichiers joints.
L'indication de fichier DDM (data distributed management) n'est autorisée que pour des
fichiers logiques créés sur un système distant.
17.3 Niveau joint
Ce niveau n'existe que pour les fichiers joints.
0001.00
0001.01
0002.00
0003.00
0004.00
0005.00
0006.00
0007.00
0008.00
0009.00
R LENENR
J
ENCRCD
ENCDCT
ENCEDI
LICQTE
LICQET
LICQDU
K ENCRCD
JFILE(ENCP LICP)
JOIN(ENCP LICP)
JFLD(ENCRCD LICRCD)
JREF(ENCP)
JDUPSEQ
Ce mot clé indique dans quel ordre les enregistrements des joints doubles sont présentés en
lecture.
Le format est :
JDUPSEQ(nom de champ !*DESCEND!)
Le nom du champ indiqué ne peut être un champ de joint.
JFLD
Ce mot clé indique les noms des deux champs dans le fichier origine et le fichier destination
qui doivent contenir une valeur identique afin de créer le joint. Si le mot clé JOIN n'est pas
spécifié, la colonne 17 doit contenir un "J".
Le format est :
57
JFLD(nom du champ départ nom du champ destination)
Il est impératif d'indiquer au moins un JFLD par JOIN déclaré.
JOIN
Ce mot clé permet d'indiquer les fichiers joints deux à deux. La colonne 17 de la spécification
doit contenir un "J".
Le format est :
JOIN(fichier origine fichier destination)
Chaque fichier indiqué doit avoir été déclaré dans le mot clé JFILE.
17.4 Niveau champ
CONCAT
Ce mot clé permet de concaténer un ou plusieurs champs d'un fichier physique pour n'en
former qu'un seul dans un fichier logique. La zone résultante doit être indiquée dans les
colonnes 19 à 28 de la spécification A.
Le format est :
CONCAT(champ 1 champ 2 ...n)
Un champ indiqué comme paramètre du mot clé CONCAT et la zone résultante de ce même
mot clé ne peuvent être indiquées simultanément comme zone clé d'un fichier logique.
JREF
Ce mot clé est a utiliser pour les bases de données plus ou moins bien définies. Il sert à
indiquer pour les zones de jointure dans quel fichier physique sera prise la valeur de la zone
au cas où le nom de zone est identique dans plusieurs fichiers physiques et que l'usage du mot
clé REFFLD a été omis pour définir la zone dans les fichiers secondaires.
Le format est :
JREF(nom fichier ou no relatif de fichier)
Le no relatif correspond à l'ordre décrit au mot clé JFILE. Si un fichier physique est décrit
deux fois avec le mot clé JFILE vous devez impérativement utiliser le no relatif de fichier.
Si aucun nom de zone n'est indiqué plusieurs fois dans différents fichiers, ce mot clé n'est pas
à utiliser.
RENAME
Ce mot clé est a utiliser lorsque vous désirez modifier la description d'un champ dans un
fichier logique par rapport à sa description dans un fichier physique.
Le format est :
RENAME(nom fichier physique nom de champ)
58
Ce mot clé peut être utilisé plusieurs fois dans le même format d'enregistrement avec le même
nom de champ comme paramètre. Cela permet soit d'utiliser le fichier avec des programmes
indiquant des noms de zones différents (comme en COBOL où des noms de zones peuvent
avoir 30 cs de long), soit de mapper un champ d'un fichier physique dans deux ou plusieurs
champs du logique, ou encore d'utiliser plusieurs noms différents pour une même zone
mémoire.
SST
Ce mot clé permet de définir une sous chaîne d'un champ alpha ou hexadécimal.
Le format est :
SST(nom de champ position départ longueur)
Nom de champ identifie un champ qui doit être déjà indiqué comme zone du fichier logique
dans une spécification précédente ou il doit exister dans le fichier physique indiqué au mot clé
PFILE ou JFILE.
Le champ résultant indiqué dans les colonnes 19 à 28 est du même type que le champ
paramètre du mot clé. Si le type de données n'est pas indiqué il sera par défaut de type H
(hexadécimal) ou A (alpha).
L'usage de la zone résultante doit être I (input) ou N (neither).
La longueur du champ résultant est optionnelle si longueur est indiqué comme paramètre.
Mais l'un ou l'autre doivent être indiqués ou les deux et égaux.
Vous ne pouvez pas indiquer simultanément les mots clé CONCAT, RENAME ou TRNTBL
avec le mot clé SST.
Le champ indiqué comme paramètre ne peut être défini antérieurement avec les mots clé
CONCAT, SST ou TRNTBL.
TRNTBL
Ce mot clé sert à indiquer qu'il faut utiliser une table de traduction entre le fichier physique et
le fichier logique pour présenter les valeurs de ce champ.
Le format est :
TRNTBL(nom librairie/nom de table de traduction)
L'usage de ce mot clé n'est valide que pour les zones alpha en entrée seulement (I) ou N
(neither).
La traduction est faite au moment de la lecture dans le fichier physique. Si d'autres opérations
de classement ou de sélection sont indiquées pour ce champ elles sont faites après traduction.
17.5 Niveau clé
59
ABSVAL
format : pas de paramètres
ABSVAL est utilisé afin de ne pas tenir compte du signe auquel le champ est assigné. Les
enregistrements sont classés selon leur séquence en tenant compte de leur valeur absolue.
ABSVAL ne peut etre associé à un champ de type alpha et ne peut être utilisé avec les motsclé suivant : DIGIT,SIGNED,UNSIGNED et ZONE.
Nota : si absval est associé avec le mot clé ALTSEQ ce dernier est ignoré.
DESCEND
C'est un mot clé de NIVEAU CLE qui permet d'accéder aux valeurs du champ clé en ORDRE
DECROISSANT.
La valeur par défaut est par ordre croissant. Le type de la valeur du champ clé peut être soit
numérique soit caractère.
DIGIT
Ce mot clé est l'équivalent inverse du mot clé zone (Voir ce mot clé). Il ne s'occupe que de la
partie droite de chaque octet de la zone clé.
NOALTSEQ
Utilisé lors de la creation de fichier physique C'est un mot clé de niveau zone-clé :(K).
Annule l'effet de Altseq (mot clé de niveau fichier) pour la zone cle en regard de laquelle il est
codifie. Ainsi la table de remplacement de fichier spécifié par altseq ne s'applique pas à la
zone clé.
Utilisation :
Par exemple, pour les tris lorsque que l'on ne veut pas prendre en compte les majuscules et
minuscules
SIGNED
Ce mot clé est identique pour les fichiers logiques et les fichiers physiques.
On ne peut pas l'utiliser avec les mots-clés ABSVAL,UNSIGNED,ZONE ou DIGIT.
SIGNED (mot clé de niveau champ) est incompatibe avec ALTSEQ (mot clé de niveau
fichier).
Si vous spécifier SIGNED pour un champ clé, NOALTSEQ est actif pour ce champ clé meme
si ALTSEQ est précisé au niveau du fichier. Ceci se passe que NOALTSEQ soit précisé ou
pas.
Ce mot clé de niveau clé est utilisé pour préciser que l'OS400 doit tenir compte des signes des
valeurs quand il classe les clés. Ce mot-clé n'est pas valide pour un champ alpha-numérique
60
(ce mot-clé n'a pas de paramétres). Par défaut, sans mot clé de rangement précis et sans le
mot-clé ALTSEQ le champ est considéré signé.
UNSIGNED
C'est le fait d'ignorer le signe d'un champ numérique.
Utilisez ce mot clé de niveau clé pour spécifier que les champs numériques soient ordonnées
comme une chaîne de donnée binaire non signée. Les champs alphanumériques sont par
défaut sensés contenir des valeurs non signées.
UNSIGNED est valide dans les champs clé du fichier physique sans tenir compte de quelle
type de donnée il s'agit. Vous ne pouvez pas spécifier le mot clé UNSIGNED avec les mots
clé SIGNED ou ABSVAL.
Le mot clé UNSIGNED est pris par défaut dans les situations suivantes :
- Quand ALTSEQ est spécifié au niveau fichier pour un champ clé zoné,
- Quand ZONE ou DIGIT est spécifié pour un champ clé zoné,
- Pour tous les champs alphanumériques.
Remarque : Spécifier UNSIGNED pour les champs de type virgule flottante peut donner des
résultats non attendus.
ZONE
Ce mot clé n'a pas de paramètre.
Le mot clé ,lorsqu'il est utilisé spécifie qu'au niveau des champs,seul les 4 premiers bits à
gauche sont pris en compte pour servir de clé (seuls les quatre premiers bits les plus à gauche
sont donc pris en compte), le reste du champ est remplacé par des zéros.
Ce mot clé porte néanmoins sur la totalité du champ-clé et non sur la partie prise en compte
exclusivement.
ZONE est incompatible avec ABSVAL ou avec SIGNED ou DIGIT.
Si vous associez le mot ZONE à un champ-clé,la valeur de ce champ est traitée comme une
chaîne de caractères binaire non signée.
exemple:
valeur
hexadécimal
comme-clé
A
C1
C
B
C2
C ==> partie prise
C
C5
C
en compte
comme clé
REPRESENTATION
0040
K
CODE
ZONE
61
17.6 Niveau sélection/omission
Ce niveau est identifié par le caractère "S" ou "O" indiqué en colonne 17 d'une spécification A
de description de fichier logique.
ALL
Ce mot clé indique quelle attitude prendre pour les enregistrements qui ne répondent pas aux
critères de sélection ou omission décrits précédemment.
L'action menée est dépendante de la valeur "S" (sélection) ou "O" (omission) indiquée en
colonne 17 de la ligne où figure le mot clé.
L'usage de ce mot clé bien que facultatif est vivement recommandé pour éviter tout résultat
inattendu. La valeur utilisée par défaut étant opposée à la valeur indiquée en colonne 17 de la
dernière ligne de sélection/omission.
COMP
Voir la définition de ce mot clé au chapitre fichiers physiques.
RANGE
VALUES
************** Début des données ***********************************
0001.00 A
DYNSLT
0002.00 A
R COMENR
JFILE(ENCP DECP CLIP ARTP)
0003.00 A
J
JOIN(ENCP DECP)
0004.00 A
JFLD(ENCNCM DECENC)
0005.00 A
JDUPSEQ(DECART)
0006.00 A
J
JOIN(ENCP CLIP)
0007.00 A
JFLD(ENCCLI CLINUM)
0008.00 A
J
JOIN(DECP ARTP)
0009.00 A
JFLD(DECART ARTCOD)
0010.00 A
ENCNCM
0011.00 A
ENCCLI
0012.00 A
ENCDCM
0013.00 A
ENCFCM
0014.00 A
ENCVCM
0015.00 A
ENCMCM
0016.00 A
DECENC
0017.00 A
DECART
0018.00 A
DECQCT
0019.00 A
DECQLT
0020.00 A
DECUPR
0021.00 A
CLINUM
0022.00 A
CLIRAI
0023.00 A
ARTCOD
0024.00 A
ARTDES
0025.00 A
K ENCCLI
0026.00 A
K ENCDCM
0027.00 A
S ENCFCM
COMP(NE 'O')
62
0028.00 A
O ENCVCM
COMP(EQ 'N')
*************** Fin des données *******************************
18 Autres fonctions base de données
18.1 National Language Support
En V3R1 le premier pas vers la mise en oeuvre de Unicode a été effectué en encodant les
noms d'objets dans certains composants de IFS. Avec la V3R6 ce support a été étendu pour
permettre aux fichiers BD de stocker des données dans Unicode (USC2 niveau 1). Par
exemple des données en français, en allemand, en hébreu, en chinois, en russe ou en toute
autre langue peuvent coexister dans un même fichier BD. SQL a la possibilité de convertir de
et vers Unicodeafin que les requêtes et les manipulations sur les données Unicode puissent
être réalisées dans une même application.
18.2 Predictive Query Governor
La plupart des bases de données comportent un genre de Query Predictor, qui permet de
s'assurer que les requêtes ne s'exécutent pas pendant un temps anormalement long. Au bout
d'un certain temps, cet outil stoppe la requête en cours si elle dépasse le temps prévu. Dans
DB2/400 si la prévision dépasse une certaine limite la requête nest même pas lancée. Ainsi les
ressources du système ne sont pas gaspillées à exécuter une requête qui serait arrêtée de toutes
façons.
Un optimiseur de requêtes est utilisé pour analyser comment il faut attaquer la base avant
l'exécution d'une requête et quel est le meilleur moyen d'y parvenir dans le temps imparti. La
prédiction de la durée d'exécution fait partie de l'analyse réalisée par l'optimiseur. Ce temps
prévu est mis en regard de la limite associée à cet utilisateur. Si la durée calculée est
supérieure à la limite autorisée, un message est envoyé à l'utilisateur qui peut choisir soit de
stopper, soit d"exécuter malgré le dépassement de limite.
18.3 Amélioration des performances
On peut utiliser la commande EXPLAIN pour prévoir ou visualiser les caractéristiques
d'exécution d'une requête. Ceci est aussi réalisé dans l'historique du travail si le programme
qui lance la requête est en mode DEBUG actif. On peut alors utiliser les informations
recueillies pour améliorer les performances soit en modifiant la base de données, soit en
modifiant la requête.
Pour les accès séquentiels l'utilisateur peut mettre en oeuvre des mécanismes de cache très
pointus comme le cache statique ou l'expert cache. Un cache expert s'agrandit ou s'amenuise
en fonction des besoins. Ce type de cache utilise des algorithmes d'intelligence artificielle (IA)
pour modifier dynamiquement la taille du cache, en fonction de la charge CPU, des prévisions
d'activité de la base de données et des ressources allouées. De même un utilisateur peut définir
un cache statique en mémoire pour permettre à une table complète ou à une portion de table
d'entrer dans une zone de mémoire.
18.4 Bases de données distribuées
63
L'AS400 permet à un programme applicatif d'accéder de façon transparente à une base de
données situées sur un autre système de la même manière que si elle était en local. Autrement
dit un programme peut traiter un fichier sans savoir réellement où il se trouve physiquement.
La possibilité d'accéder à une base de données distante et pour d'autres systèmes d'avoir accès
à la base de données locale est réalisée grâce à la mise en oeuvre de deux architectures :
- DRDA (Distributed Relational Database Architecture) pour SQL,
- DDM (Distributed Data Management) pour les accès en natif.
18.5 Passerelles vers d'autres SGBDR
L'AS400 fonctionne avec les bases de données supportant DDM ou DRDA, mais il offre
également une approche intégrée pour accéder aux autres bases de données. Ce support
permet de travailler directement avec n'importe quel SGBD d'un autre constructeur présent sur
le réseau. En plus de la Distributed Database Directory de l'OS400, il ya un Distributed Driver
Manager. Ce gestionnaire fonctionne avec les drivers des différentes bases de données Unix et
Micro et permettent à une application AS400 de travailler avec ces bases de données de la
même manière qu'avec une base de données DRDA.
En sortie, le support d'un driver ODBC est également disponible pour les bases compatibles
avec l'architecture distribuée de Microsoft.
18.6 Data Propagator
Dans un environnement distribué il peut exister plusieurs exemplaires d'un même fichier sur
des systèmes distincts. La modification de l'un des exemplairesn'est pas immédiatement
répercutée sur les autres exemplaires. Data Propagator fourni un mécanisme de répercussion
des mises à jour sur tous les systèmes. A intervalles définis par l'utilisateur, les modifications
d'un fichier donné sont répliquées à travers l'ensemble des systèmes même si tous ne sont pas
connectés au réseau simultanément. Les modifications peuvent être répercutées sur toute base
DB2 aussi bien sous OS/2 que sous AIX ou MVS.
18.7 Opticonnect
Comme système isolé, l'AS400 admet des configurations assez importantes. Mais pour des
clients ayant des besoins allant au delà de ce qu'il est possible de faire avec un seul AS400 et
même avec un réseau de systèmes, les charges liées au trafic réseau vont limiter les
performances. Opticonnect pour l'OS400 permet à plusieurs AS400 d'être reliés entre eux par
fibre optique. Dans une telle configuration, certaines machines seront réservées aux
traitements applicatifs et d'autres machines seront spécialisées pour les traitements base de
données.
Opticonnect met en oeuvre DDM, mais avec un protocole particulier qui élimine les couches
redondantes de contrôle de transmission liées aux lignes LAN bruyantes. Avec Opticonnect il
faut seulement ajouter 3 millisecondes au temps nécessaire pour accéder à la base de données
qui oscile de 3 à 8 millisecondes en temps normal et selon les modèles de DASD (Data
Auxillary Storage Drive).
64
19 Bases de données parallèles
Dans un système tel que l'AS400, avec de multiples processeurs, les opérations base de
données peuvent être partagées entre plusieurs processeurs pour atteindre un haut niveau de
performances. Par exemple, un requête peut être divisée en sous requêtes, chacune s'exécutant
sur des processeurs distincts et sur des machines distinctes. Deux approches permettent de
réaliser de telles améliorations.
19.1 La base de données SMP (Symetric Multiprocessing Parallel)
Disponible sur les AS400 multiprocesseurs. Les requêtes sont fractionnées en unités de travail
plus petites, réparties ensuite entre les processeurs, en une répartition équitable de la charge
sur les différents processeurs. La commande CHGQRYA (Change Query Attributs) comporte
une option permettant à l'utilisateur que la requête doit mettre à proffit les processeurs
multiples.
19.2 La base de données faiblement associée
Ce support de base de données répartie permet à de multiples AS400 de s'interconnecter pour
fonctionner comme une seule base de données. On appelle ce type d'interconnection une
grappe faiblement associée, parce que chaque système (un noeud ou node) de la grappe tourne
avec son propre système d'exploitation et ne peut adresser que sa propre mémoire.
Dans l'absolu, il n'y a pas de limite au nombre de connections, mais pour l'instant seulement
32 systèmes peuvent être interconnectés. Cela correspond à une base de données de 16 To
avec 128 processeurs tournant en parallèle, ce qui n'est pas si mal pour un début.
Pour la mise en oeuvre, voir les commandes :
- CRTNODGRP create node group,
- CHGNODGRPA change node group attributs,
- CRTPF mots clé NODGRP et PTNKEY (partitionning key),
- CREATE TABLE pour accès SQL.
65
20 Sécurité des données
20.1 La journalisation
Un journal est l'enregistrement chronologique des modifications apportées à un ensemble de
données. Le but du journal est d'offrir la possibilité de reconstruire une version précédente de
cet ensemble de données.
Deux objets AS400 servent de support à la journalisation. L'un est le journal, l'autre le
récepteur de journal. Le journal identifie les objets à journaliser, le récepteur de journal
contient les entrées de journal (les modifications effectuées).
Chaque entrée de journal contient plusieurs éléments d'information, dont le nom du fichier, de
la bibliothèque, le nom du programme, le numéro relatif d'enregistrement, l'heure et la date,
l'identification du travail, de l'utilisateur et du poste de travail. La copie de l'enregistrement
modifié est également inscrite, et optionnellement, la copie avant modification peut aussi être
inscrite.
Les journaux de base de données sont utilisés pour pouvoir reprendre après une panne
système, mais aussi après des problèmes de base de données liés à des programmes. S'il se
produit une anomalie, les fichiers journalisés sont automatiquement restaurés lors de l'IPL
suivant. Il est possible de restaurer soit en avant soit en arrière. La restauration supprime les
modifications erronées du fichier.
20.2 La protection des chemins d'accès par le système (SMAPP)
IBM a conçu SMAPP (System Managed Access Path Protection) pour réaliser une
journalisation automatique des chemins d'accès fichiers, ntamment pour les utilisateurs qui
n'utilisent pas la journalisation explicite.
Le système calcule automatiquement la durée maximale qu'il va allouer à la reconstruction des
chemins d'accès pendant l'IPL après un arrêt anormal. Il utilise ensuite cette durée maximale
pour déterminer combien il faut journaliser de chemins d'accès. L'utilisateur a la possibilité de
modifier cette valeurcalculée dans un sens ou dans l'autre. Plus la valeur est petite, plus il
faudra de ressources à la journalisation, plus la valeur est grande, plus l'IPL durera dans le
temps.
20.3 Le contrôle de validation
Lorsque de multiples mises à jour de plusieurs tables sur une seule opération sont nécessaires,
il est possible que de par l'action de l'utilisateur final ou de par une anomalie de
fonctionnement, une partie seulement des mises à jour soient effectuées. Si la situation en
reste là, l'intégrité de la base de données est compromise. Le système doit donc gérer la
possibilité de prendre en compte ou d'annuler un groupe de mises à jour. Celà s'appelle le
contrôle de validation. Le système doit donc protéger un groupe de mises à jour et ne les
libérer que lorsque toutes les mises à jour sont effectuées. Une opération COMMIT permet au
système d'enterriner un groupe de modifications, alors que l'opération ROLLBACK permet
d'invalider un groupe de mises à jour. Le contrôle de validation utilise la journalisation pour
mettre en oeuvre ces opérations.
66
20.4 DASD de technologie RAID 5
Les disques sont mécaniques et tout ce qui est mécanique est suceptible de tomber en panne. Il
existe deux techniques on line pour protéger les données. La technique des disques miroir
(mirroring) et la technique de duplication partielle sur grappes de disques.
La technique des disques miroir oblige à une configuration dupliquée avec copie systématique
de toutes les opérations sur deux unités de disques différentes. Le système continue à
fonctionner si une unité de disque tombe en panne, mais est indisponible dans le cas
statistiquement hautement improbable où les deux unités tombent en panne simultanément.
Les disques miroir offrent le maximum de disponibilité mais sont une solution coûteuse
surtout si on duplique aussi les IOP et les BUS, ce qui offre le maximum de sécurité.
Une autre approche consiste à utiliser des disques en grappe. Les informations sont réparties
sur tous les disques et ont utilise un disque redondant. De cette manière, si un des disques
tombe en panne, il est possible de reconstituer l'ensemble de l'information. Cette technologie
est appelée RAID (Redondant Array of Inexpensive Disk). La technique consiste à effectuer
une opération XOR sur les données de tous les secteurs du groupe. l'opération XOR entre
deux opérandes permet de retrouver un des opérandes par un nouveau XOR entre l'autre
opérande et le résultat. Les résultats sont stockés sur le disque redondant. Ainsi toute donnée
perdue par une panne d'un des disques peut être reconstituée par un disque plus le résultat du
dsique redondant. Si c'est le disque redondant qui est en panne, tioutes les infos initiales sont
disponibles.
67
21 Limitations
Les limitations actuelles sont le fait de la version actuelle du SLIC, dans l'absolu le MI n'a pas
de limite à la taille des objets système car il est indépendant de la technologie. Par le passé, les
limitations ont déjà été repoussées plusieurs fois.
Element
Taille maxi
PF
nombre d'enregistrements par PF
LF
clé composée ou simple
PF par LF joint
champ de type CHAR
champs par record
Nom d'un fichier DB
240 Go
> 2 000 000 000
4 Go
2048 octets
32
32 767 octets
32 767
18 caractères

Les données et l`as400 le SGBDR DB2/400

Transcription

Documents pareils

ROUBEYRIE Olivier

ingenieur d`etudes

Pierre TERRIER 14, rue marius aufan 92300

Beatrice DEWEZ - Analyste/programmeur

Perfectionnement

CA Log Analyzer™ for DB2 for z/OS

Architecture client serveur l`état de l`art

DB2 7.1 : SQL/XML - Les cahiers de l`IBM i

chargé d`assistance informatique de la gestion des données…