LES DONNÉES ET L'OS400 le SGBDR DB2/4003kernels.free.fr/divers/support/ipi/as400/db2-400.pdf ·...

of 67/67
OS400-04 © Institut de Poly-informatique (1995) OS40004.DOC LES DONNÉES ET L'OS400 le SGBDR DB2/400 Auteur : Dominique Vignez
  • date post

    06-Feb-2018
  • Category

    Documents

  • view

    220
  • download

    1

Embed Size (px)

Transcript of LES DONNÉES ET L'OS400 le SGBDR DB2/4003kernels.free.fr/divers/support/ipi/as400/db2-400.pdf ·...

  • OS400-04

    Institut de Poly-informatique (1995) OS40004.DOC

    LES DONNES ET L'OS400

    le SGBDR DB2/400

    Auteur : Dominique Vignez

  • DB2/400 les donnes et l'OS400 2

    Institut de Poly-informatique (1995)

    Cette page est laisse intentionnellement blanche

  • DB2/400 les donnes et l'OS400 3

    Institut de Poly-informatique (1995)

    Table des matires 1 Introduction................................................................................................................7 2 Traitement des donnes par l'AS400 .........................................................................7 3 Description des fichiers .............................................................................................8

    3.1 Description au niveau enregistrement............................................................8 3.2 Description au niveau champ.........................................................................8

    3.2.1 types de donnes supports ................................................................8 4 Organisation de la Base de Donnes AS400..............................................................9

    4.1 Notion de base de donnes.............................................................................9 5 Mthodes de description des donnes au systme .....................................................10

    5.1 Outils d'aide la gestion des descriptions de donnes...................................10 5.1.1 Dictionnaire des donnes ...................................................................10 5.1.2 Fichier de rfrences de zones ...........................................................10

    5.2 Utilisation dOperation navigator ..................................................................11 5.3 Terminologie..................................................................................................11

    6 OS400 DDS ...............................................................................................................13 6.1 Niveaux informations dans un membre source de description de donnes ......................................................................................................................14

    6.1.1 Crer un membre PF ou LF................................................................16 6.2 ..............................................................................................................................17

    6.2.1 Syntaxe d'une ligne de spcification DDS .........................................17 7 OS400 IDDU .............................................................................................................20 8 SQL/400.....................................................................................................................22 9 Description l'aide de Query Manager......................................................................22 10 Description des fichiers systme................................................................................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

  • DB2/400 les donnes et l'OS400 4

    Institut de Poly-informatique (1995)

    11 volutions relatives au support de DB2 en V3R1M0................................................32 11.1 Support de IFS (Integrated File System)........................................................32 11.2 Rorganisation des tables systme .................................................................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'intgrit rfrentielle ........................................33 11.13 Support des triggers ou dclencheurs ........................................................34 11.14 ..........................................................................................................................35 11.15 Les messages escape du SGBD .................................................................35 11.16 ..........................................................................................................................36 11.17 ..........................................................................................................................36 11.18 Procdures catalogues ..............................................................................36 11.19 Validation deux phases ou two phases commit ......................................36

    12 Les fichiers de l'OS400 ..............................................................................................37 12.1 ............................................................................................................................37 12.2 Types de fichiers ............................................................................................37 12.3 Accs aux fichiers ..........................................................................................38 12.4 CONTRLE DES ACCS FICHIERS .........................................................39

    12.4.1 Open feedback area..........................................................................40 12.4.2 I/O feedback area .............................................................................40

    13 Les fichiers de donnes..............................................................................................41 13.1 Structure.........................................................................................................41

    14 Description.................................................................................................................41 14.1 fichiers physiques...........................................................................................41 14.2 Structure.........................................................................................................42

    15 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

    16 fichiers logiques .........................................................................................................53 16.1 Structure.........................................................................................................53 16.2 Logiques joints...............................................................................................53 16.3 Conversions de type de donnes ....................................................................55

    17 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 slection/omission .............................................................................61

    18 Autres fonctions base de donnes ..............................................................................62 18.1 National Language Support............................................................................62

  • DB2/400 les donnes et l'OS400 5

    Institut de Poly-informatique (1995)

    18.2 Predictive Query Governor ............................................................................62 18.3 Amlioration des performances .....................................................................62 18.4 Bases de donnes distribues .........................................................................62 18.5 Passerelles vers d'autres SGBDR...................................................................63 18.6 Data Propagator..............................................................................................63 18.7 Opticonnect ....................................................................................................63

    19 Bases de donnes parallles .......................................................................................64 19.1 La base de donnes SMP (Symetric Multiprocessing Parallel) .....................64 19.2 La base de donnes faiblement associe ........................................................64

    20 Scurit des donnes..................................................................................................65 20.1 La journalisation ............................................................................................65 20.2 La protection des chemins d'accs par le systme (SMAPP).........................65 20.3 Le contrle de validation................................................................................65 20.4 DASD de technologie RAID 5.......................................................................66

    21 Limitations .................................................................................................................67

  • DB2/400 les donnes et l'OS400 6

    Institut de Poly-informatique (1995)

  • DB2/400 les donnes et l'OS400 7

    Institut de Poly-informatique (1995)

    1 Introduction De par son caractre intgr, situ pour partie au dessus du MI et pour partie l'intrieur du SLIC, la base de donnes de l'AS400 atteint un niveau d'efficacit plus important qu'une autre base de donnes qui serait construite au dessus du systme d'exploitation. La base de donnes de l'AS400 a t conu pour le S38 ds 1975 par Perry Taylor. A cette poque E.F. Codd travaillait pour IBM sur un projet appel System/R et avait dcrit un systme relationnel de table deux dimensions, sur laquelle on pouvait raliser quatre oprations (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 annonant que les bases de donnes relationnelles ne pouvaient tre conues que pour les gros systmes et qu'un petit systme n'avait besoin que d'un tri et d'une fusion de fichiers. La premire base de donnes relationnelle tre installe sur un ordinateur fut celle du S38 en 1978, mais sans l'opration join. Trois ans plus tard, la base de donnes du systme/R fut commercialise sous le nom de DB2 et comme elle possdait les quatre oprations, il fut dcrt qu'elle tait finalement la premire base de donnes relationnelle au monde. Comme il n'existait pas d'interface standard aux bases de donnes relationnelles l'poque o la base de donnes du systme 38 a t lance, il a fallu dvelopper une interface native : les DDS. Les spcifications du langage SQL ne sont venues que plus tard et une dcennie a t ncessaire leur stabilisation. Ceci explique que les DDS sont livres encore aujourd'hui en standard alors que le kit de dveloppement SQL est fourni en option. Cette ncessit historique fait que longtemps le SQL a t moins performant et quasiment inutilis sur AS400. La rcriture du SGBD DB2/400 avec la V3.R1. de l'OS400 a gomm cette diffrence. DDS et SQL sont maintenant au mme niveau de performances sur l'AS400. 2 Traitement des donnes par l'AS400 L'AS400 est une machine conue pour s'intgrer dans l'AUA d'IBM (Architecture unifie d'applications) et pouvant assurer la compatibilit avec la gamme 3X ou avec la gamme gros systmes et mme micro sous OS/2 ou AIX pour RS/6000. Sur une mme machine il est donc possible de grer les donnes de plusieurs faons suivant les finalits recherches. 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 dcrira pas les donnes de la mme manire et on ne les traitera pas non plus de la mme manire.

  • DB2/400 les donnes et l'OS400 8

    Institut de Poly-informatique (1995)

    3 Description des fichiers 3.1 Description au niveau enregistrement Elle correspond l'utilisation traditionnelle sans base de donnes. Seule la longueur de l'enregistrement est dcrite au systme. Le systme ne connat rien des champs contenus dans le fichier. La description des champs n'tant donne qu' l'intrieur des programmes. Cette faon de procder est appele "fichiers description interne". Dans ce cas les donnes sont strictement dpendantes des programmes. 3.2 Description au niveau champ Elle correspond l'utilisation avec base de donnes dj utilise sur le systme 38. L'ensemble des lments dcrire pour un champs comprend : - le nom, - la longueur, - le type, - les domaines de validit, - un texte descriptif. Cette faon de procder est appele "fichiers description externe". Dans ce cas les donnes sont indpendantes des programmes. 3.2.1 types de donnes supports Le type de donnes est indiqu en colonne 35 d'une spcification de description de donnes (A) voir annexes les types possibles sont : - P numrique dcimal pack, - S numrique dcimal zon, - B numrique binaire, - F numrique flottant, - A alphabtique, - H hexadcimal, - L date, - T heure, - Z horodatage. Si le type de donnes n'est pas explicitement indiqu le systme attribuera par dfaut le type A (alpha) si ne nombre de dcimales (colonne 36,37) est blanc, ou pack si le nombre de dcimales est de 0 31. Indiquer 0 dcimale en colonnes 36 37 dsigne un entier pour des zones dfinies en pack, zon ou binaire. Si le type est F (virgule flottante) il faut spcifier le mot cl FLTPCN pour indiquer la simple ou la double prcision du nombre flottant.

  • DB2/400 les donnes et l'OS400 9

    Institut de Poly-informatique (1995)

    Le type hexadcimal permet d'indiquer au systme qu'il ne doit pas interprter le contenu de ce champ et le restituer tel quel. Dans la plupart des cas un champ dfini en hexadcimal sera trait sur les mmes rgles qu'un champ alpha. 4 Organisation de la Base de Donnes AS400 Sur AS400 il existe 4 mthodes pour dcrire les donnes : - 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 mthode utilise l'environnement systme et les possibilits sont diffrentes mais toujours complmentaires. 4.1 Notion de base de donnes Sur AS400 une base de donnes est un ensemble de fichiers physiques et logiques contenus dans une mme bibliothque. Conceptuellement une base de donnes ne peut pas contenir d'autres bases de donnes. L'arborescence est donc limite sa plus simple expression. Seule la base de donnes du systme (QSYS) qui est la racine, peut contenir d'autres bases de donnes. Le gestionnaire systme de la base donnes, n'a donc grer que deux niveaux hirarchiques. 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 propritaire, - 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).

  • DB2/400 les donnes et l'OS400 10

    Institut de Poly-informatique (1995)

    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 dpendant, - librairie du fichier dpendant, - type de dpendance (Donnes, Vue, Index). Deux fichiers logiques sont bass sur QADBXREF se sont QADBXFIL, QADBXDIC et deux fichiers logiques sont bass sur QADBFDEP se sont : QADBLDEP et QADBLDNC pour simplifier les accs. Lorsque l'on dcrit les donnes avec la mthode des DDS, seule cette configuration est en oeuvre associe la description des champs contenue dans le fichier lui mme. 5 Mthodes de description des donnes au systme Si vous dsirez dcrire un fichier uniquement au niveau enregistrement, vous pouvez utiliser le paramtre de longueur d'enregistrement (RCDLEN) en utilisant la commande de cration de fichier physique CRTPF. Si vous dsirez dcrire un fichier au niveau champs, vous pouvez utiliser plusieurs mthodes : l'utilitaire IDDU (interactive data description utility), les commandes SQL/400, ou les DDS (data description specifications). Les DDS offrant le maximum des possibilits de descriptions offertes au programmeur, c'est souvent cette mthode que vous utiliserez. 5.1 Outils d'aide la gestion des descriptions de donnes Afin d'viter les doubles dfinitions de donnes et dans un souci de standardisation, il est possible d'utiliser soit un dictionnaire de donnes soit un fichier de rfrences de zones. 5.1.1 Dictionnaire des donnes Un fichier description interne peut tre dcrit dans un dictionnaire de donnes pour le dtail du ou des formats d'enregistrements surtout si ce fichier doit tre utilis par QUERY/400, PCS/400 ou DFU. De mme un fichier description externe peut galement tre dcrit dans un dictionnaire. Le systme s'assurant que les deux dfinitions soient bien identiques. 5.1.2 Fichier de rfrences de zones L'ensemble des dtails de description des champs peut tre contenu dans ce fichier, vitant ainsi au programmeur des redfinitions longues et sources d'erreurs.

  • DB2/400 les donnes et l'OS400 11

    Institut de Poly-informatique (1995)

    L'utilisation de ce fichier accrot la productivit du programmeur et garanti l'uniformit des descriptions de donnes d'un programmeur l'autre. 5.2 Utilisation dOperation navigator

    Operation Navigator permet de grer la base de donnes par interface graphique. Les requtes SQL sont gnres automatiquement par linterface. A partir de la V4.R4. cest loutil le plus puissant de lAS400 pour grer les possibilits de DB2 Universal DataBase. 5.3 Terminologie Suivant la mthode employe les notions logiques de mmes entits peuvent tre nommes diffremment. La liste suivante donnera les termes pour une organisation traditionnelle puis selon l'OS400 puis selon SQL . rpertoire librairie collection fichier fichier physique table index secondaire fichier logique vue enregistrement format range ou tupple item champs colonne ou attribut

  • DB2/400 les donnes et l'OS400 12

    Institut de Poly-informatique (1995)

    Ces termes bien que regroupant des conceptions identiques ne sont pas simplement des homonymes mais bien des entits diffrentes qui ne peuvent tre utilises l'une pour l'autre. Ces parallles ne sont faits que pour aider la comprhension. Pour de plus amples informations sur ce sujet, consultez les brochures IBM programming data base guide, programming data management guide.

  • DB2/400 les donnes et l'OS400 13

    Institut de Poly-informatique (1995)

    6 OS400 DDS Les fichiers description externe peuvent tre dcrits en utilisant le langage de description de donnes. Il s'appelle : DDS : Data Description Spcification en anglais. SDD : Spcification de Description de Donnes en franais. Il sert dcrire les donnes dans des membres source : . de Base de donnes : membres source PF et LF. . d'affichage : membres source DSPF. . d'impression : membres source PRTF. . de communications : membres source ICFF. ... etc. Chaque ligne d'un membre de donne = une spcification. Chaque spcification 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 dcrire les cls du chemin d'accs d'un fichier logique par exemple. Ceci contrairement SQL qui vous permettra de dcrire des vues.

  • DB2/400 les donnes et l'OS400 14

    Institut de Poly-informatique (1995)

    La colonne 17 de la spcification 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 slection, - 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 dcrite prcdemment au dans un autre fichier Indiqus au mot cl REFFLD. Les colonnes 30 34 peuvent contenir la longueur de la zone (cadre droite). La colonne 35 indique le type de donnes (voir ci-dessus types de donnes). Les colonnes 36 37 peuvent contenir le nombre de dcimales (cadre droite) pour la description d'une zone numrique. Un nombre de dcimales gal zro indique une zone numrique entire. La colonne 38 dcrit l'usage de la zone et n'est gnralement pas utilise pour les fichiers base de donnes. Les valeurs possibles sont : - I (Input) entre, - O (Output) sortie, - B (Both) entre sortie, - H (hidden) cach, - M (Message), - P (Program to system), - N (Neither) ni entre 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 utilises que pour les fichiers crans ou imprimantes et pas pour les fichiers base de donnes. Les colonnes 45 80 sont utilises pour indiquer les mots cl. Voir ci-dessous les diffrents 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

    donnes

  • DB2/400 les donnes et l'OS400 15

    Institut de Poly-informatique (1995)

    Un membre source de description de donnes contient des informations organises en niveaux. Ces niveaux ont un ordre respecter. Certains niveaux peuvent tre ignors 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 slection.

  • DB2/400 les donnes et l'OS400 16

    Institut de Poly-informatique (1995)

    6.1.1 Crer un membre PF ou LF La cration d'un membre source PF permet la cration d'un fichier de donnes. 1) Avant de crer un membre PF, il faut connatre les informations suivantes sur le fichier : - le fichier rpertoire qui contient la description des zones fichiers, - s'il y a prsence 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 slections faire sur les donnes ( pour LF uniquement ). 2) Il faut organiser ces informations en niveaux : Au niveau fichier : - donner le nom du rpertoire de description des zones, - dire si la cl est unique ou pas ( en cas de prsence 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 :

  • DB2/400 les donnes et l'OS400 17

    Institut de Poly-informatique (1995)

    - donner le nom de la zone, - si la zone est rfrence :

    - dire si elle fait rfrence au rpertoire cit au niveau fichier ou si elle fait rfrence une autre zone,

    - si la zone n'est pas rfrence : - donner sa longueur et son type; - donner infos complmentaires. 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 slection omission : - dcrire la/les slections et/ou omissions de donnes. 3) Crer le membre PF ou LF sous PDM : Crer un nouveau membre de type PF ou LF. Pour saisir une ligne : insrer une ligne avec l'invite DP : IPDP (voir pages suivantes pour la syntaxe DDS) 4) Compiler le membre PF ou LF pour crer le fichier BD : utilisez l'option 14 de PDM (si besoin F4 pour les options et optimisations). Attention : il y a un ordre de cration des diffrents fichiers de la BD. - crer d'abord le rpertoire de donnes, - crer ensuite les fichiers Physiques, - crer enfin les fichiers Logiques. 6.2 6.2.1 Syntaxe d'une ligne de spcification DDS

  • DB2/400 les donnes et l'OS400 18

    Institut de Poly-informatique (1995)

  • DB2/400 les donnes et l'OS400 19

    Institut de Poly-informatique (1995)

  • DB2/400 les donnes et l'OS400 20

    Institut de Poly-informatique (1995)

    7 OS400 IDDU Les fichiers physiques peuvent tre dcrits en utilisant IDDU. L'avantage d'utiliser IDDU est que c'est une mthode interactive avec accs par menus pour dcrire les donnes. Il se peut galement que des utilisateurs connaissant le systme 36 en aient l'habitude et prfrent cette mthode. 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 dcrire vos fichiers, les dfinitions de fichiers deviennent des lments d'un dictionnaire de donnes OS/400. Si vous dsirez de plus amples informations ce sujet consultez la brochure IBM IDDU user's guide. Lorsque l'on utilise la mthode IDDU, une base de donnes utilisateur, donc une librairie contient en plus des fichiers de donnes les objets suivants : - un dictionnaire de donnes (DTADCT) portant le nom de la base de donnes. - 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 squence des champs et mode de traitement, QIDCTP25 squence 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 cre un enregistrement, QIDCTP53 relations entre un enregistrement et les fichiers physiques sur lesquels il est bas. - 7 fichiers logiques bass sur les prcdents : 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 ncessaires l'utilitaire IDDU pour assurer sa fonction de description de donnes interactive. Mais IDDU n'est capable de crer que des fichiers physiques. Par contre il peut grer les dfinitions de fichiers logiques. Un fichier cr par la mthode des DDS peut voir ses dfinitions gres par IDDU la condition que celles ci soient entres dans le dictionnaire par la commande ADDDTADFN.

  • DB2/400 les donnes et l'OS400 21

    Institut de Poly-informatique (1995)

    Nanmoins les fichiers partageants un chemin d'accs, ayant une squence de classement alterne ou tant en union, les fichiers joints et les fichiers logiques en select ou en project ne sont pas grables par IDDU.

  • DB2/400 les donnes et l'OS400 22

    Institut de Poly-informatique (1995)

    8 SQL/400 Le langage de requte structur SQL/400 peut tre utilis pour pour dcrire une base de donnes AS/400. SQL/400 supporte les instructions pour dcrire les champs d'une base de donnes, et pour crer les fichiers. Si l'application que vous dveloppez doit s'inscrire dans un contexte de portabilit entre systmes, il sera prfrable de dcrire vos donnes par SQL. Pour de plus amples informations ce sujet, consultez la brochure IBM SQL/400 programmer's guide. Lorsque l'on utilise la mthode SQL, l'environnement s'enrichi encore et la base de donnes devient une collection par adjonction des lments suivants : - QSQJRN journal associ au contrle de validation SQL, - QSQJRN0001 rcepteur 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 mmes bases que le prcdent; 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 ncessaire pour crer des tables, des vues, des enregistrements par SQL. Mais pour grer les donnes en lecture, en mise jour ou en ajout l'aide de SQL, il n'est pas indispensable que ces dernires soient incluses dans une collection. SQL400 est capable de grer les donnes de l'AS400 quelque soit leur mode de dfinition. 9 Description l'aide de Query Manager Query Manager est un outil offrant une interface utilisateur pour utiliser le langage SQL. Il offre les mmes possibilits que IDDU et SQL runis, sans avoir recours aux fichiers systmes. Par contre et s'en est la contrepartie, il est un peu plus lent d'excution car chaque information doit faire l'objet d'un traitement pour tre accessible au lieu d'avoir effectuer une simple lecture de fichier. L'accs Query Manager se fait grce la commande STRQM (dmarrer Query Manager). En choisissant le choix 3 (gestion des tables QM) du menu qui s'affiche, une fentre permet d'indiquer la collection ou la bibliothque sur laquelle on dsire travailler.

  • DB2/400 les donnes et l'OS400 23

    Institut de Poly-informatique (1995)

    L'affichage d'un choix de bibliothque dans une liste est possible par l'intermdiaire de la touche F4. Il est possible ensuite de crer un fichier physique par l'option 1 (cration de table).

  • DB2/400 les donnes et l'OS400 24

    Institut de Poly-informatique (1995)

    10 Description des fichiers systme 10.1 Fichier QIDCTP10 Longueur d'enregistrement : 535 octets nom externe du champ id interne du champ flag interne de delete fonction de cration date de cration heure de cration id crateur date dernire modification heure dernire modification id dernier modifieur type gnral de donne (1=char, 2=numrique) type dtail de donne majuscule par dfaut longueur externe longueur interne nbre de dcimales type de donne SQL longueur SQL prcision SQL valeur nulle possible (Y=oui, N=non) code d' dition sparateur de date et heure symbole de point dcimal sparateur de milliers apparition du signe ngatif signe ngatif gauche signe ngatif droit impression de la valeur zro remplacement des zros non significatifs remplacement de la valeur zro option d' affichage des zros ngatifs affichage du symbole montaire symbole montaire gauche symbole montaire droit mot d' dition longueur entte 1 de champ entte 1 de champ longueur entte 2 de champ entte 2 de champ longueur entte 3 de champ entte 3 de champ nom alias 10.2 Fichier QIDCTP20 Longueur d' enregistrement 123 octets

  • DB2/400 les donnes et l'OS400 25

    Institut de Poly-informatique (1995)

    nom externe de l'enregistrement id interne de l' enregistrement flag interne de delete texte descriptif fonction de cration date de cration heure de cration id du crateur date de dernire modif heure de dernire modif id du dernier modificateur code de rvision du fichier physique 21 code de rvision du fichier physique 25 rserve reserve 10.3 Fichier QIDCTP21 Longueur d' enregistrement 36 octets id interne d' enregistrement code de rvision interne id interne de champ type de fichier (D=dbase) squence relative de sortie squence relative d' entre usage du champ modifiable par SQL (Y=oui, N=non) n de rfrence de joint 10.4 Fichier QIDCTP25 Longueur d' enregistrement 36 octets id interne d' enregistrement code de rvision interne id interne de champ n relatif de squence type de fichier (D=dbase) position relative dans le champ oprateur de comparaison (EQ, NE, ZN, NZ, DG, ND) valeur test id enregistrement continuation et/ou (1=and, 2=or) 10.5 Fichier QIDCTP30 Longueur d' enregistrement 134 octets nom externe du fichier id interne du fichier flag interne de delete texte descriptif date de cration heure de cration id du crateur

  • DB2/400 les donnes et l'OS400 26

    Institut de Poly-informatique (1995)

    date dernire modif heure dernire modif id du dernier modificateur type de fichier (1=physique, 2=logique) accs base de donnes (1=squentiel, 2=par cls) type de joint (1=inner join, 2=left outer join) vrification SQL (Y=oui, N=non) cls en double (D=oui, U=non) squence des cls en double (F=fifo, L=lifo) code de rvision fichier physique 31 code de rvision fichier physique 51 code de rvision fichier physique 52 code de rvision fichier physique 53 rserve rserve rserve dfinition fichier SQL 10.6 Fichier QIDCTP31 Longueur d'enregistrement 27 octets id interne fichier code rvision interne id interne d' enregistrement N de squence relatif 10.7 Fichier QIDCTP51 longueur d' enregistrement 40 octets id interne fichier code de rvision interne id interne d' enregistrement id interne de champ n de squence relatif ordre de tri de la cl (A=ascendant, D=descendant) attribut de cl (S=signe, U=non signe, A=alpha, D, Z) 10.8 Fichier QIDCTP52 Longueur d' enregistrement 86 octets id interne de fichier code de rvision interne n de squence relatif texte de la commande SQL de cration 10.9 Fichier QIDCTP53 Longueur d' enregistrement 60 octets id interne fichier code de rvision interne id interne d' enregistrement nom du fichier de base nom de la librairie du fichier de base

  • DB2/400 les donnes et l'OS400 27

    Institut de Poly-informatique (1995)

    id interne du fichier physique de base n de squence relatif squence de rfrence de joint (0=logique) 10.10 Fichier QIDCTL76 Vue logique de QIDCTP10 longueur enr. 30 octets, longueur cl 30 octets cl : Q76GUA 10.11 Fichier QIDCTL80 Index de QIDCTP10 longueur enr. 535 octets, longueur cl 21 octets cl : Q10DEN,Q10IDI nom externe zone, id interne 10.12 Fichier QIDCTL81 Index de QIDCTP20 longueur enr. 123 octets, longueur cl 21 octets cl : Q20REN,Q20IRI nom externe enr., id interne 10.13 Fichier QIDCTL82 Index de QIDCTP30 longueur enr. 134 octets, longueur cl 21 octets cl : Q30FEN,Q30IFI nom externe fichier, id interne 10.14 Fichier QIDCTL84 Vue jointe sur QIDCTP21/QIDCTP20 longueur enr. 101 octets longueur cl 11 octets cl : Q84IDI joint : QIDCTP21/Q21IRI QIDCTP20/Q20IRI id champ interne id enr. interne code rvision interne code rvision P25 squence de sortie relative nom enr. externe date cration heure cration 10.15 Fichier QIDCTL86 Vue jointe de QIDCTP31/QIDCTP30 longueur enr. 105 octets longueur cl 11 octets cl : Q86IRI joint : QIDCTP31/Q31IFI -> QIDCTP30/Q30IFI id enr. interne id fichier interne code rvision interne

  • DB2/400 les donnes et l'OS400 28

    Institut de Poly-informatique (1995)

    code rvision P51 code rvision P52 code rvision P53 n squence relatif Type fichier nom fichier externe texte descriptif date cration heure cration 10.16 Fichier QIDCTL88 Vue jointe de QIDCTP21/QIDCTP20/QIDCTP31/QIDCTP30 longueur enr. 98 octets longueur cl 11 octets cl : Q88IDI joint : QIDCTP21/Q21IRI QIDCTP20/Q20IRI QIDCTP31/Q31IRI QIDCTP31/Q31IFI QIDCTP30/Q30IFI QIDCTP31/Q31R31 QIDCTP30/Q30R31 id champ interne id fichier interne code rvision interne type fichier type de fichier base de donnes nom fichier externe texte descriptif date cration heure cration 10.17 SYSINDEXES Cette vue logique contient un enregistrement pour chaque index de la base de donnes.

    NAME char(10) nom de l'index CREATOR char(10) propritaire de l' index TBNAME char(10) nom du fichier physique TBCREATOR char(10) propritaire du fichier physique TBDBNAME char(10) nom de la librairie du fichier physique UNIQUERULE char(1) cls en double autorises 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 char(10) nom de l'index IXCREATOR char(10) propritaire de l' index COLNAME char(10) nom du champs contenu dans l' index COLNO integer n d'ordre du champs dans l'enregistrement COLSEQ integer n d'ordre du champs dans la cl

  • DB2/400 les donnes et l'OS400 29

    Institut de Poly-informatique (1995)

    ORDERING char(1) 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 TBCREATOR

    char(10) propritaire du fichier

    COLNO smallint n d'ordre du champs dans le fichier COLTYPE char(8) type de donne INTEGER entier long SMALLINT entier court FLOAT nombre flottant CHAR caractre DECIMAL dcimal pack NUMERIC dcimal zon LENGHT smallint longueur ou prcision 4 bytes integer 2 " smallint 8 " float,float(n) n=25 53 ou double prcision 4 bytes float(n) n = 1 24, rel longueur de la chane char nombre de digits decimal nombre de digits numeric SCALE smallint chelle de donne numrique (zro 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 dfaut LABEL char(30) entte de colonne STORAGE smallint besoin en espace mmoire pour le stockage du champs idem dfinition de lenght sauf pour decimal = (nbre digits /

    2) + 1 PRECISION smallint prcision d'un champs numeric (Zro si non numeric)

    10.21 SYSTABLES Cette vue logique contient un enregistrement pour chaque fichier physique ou logique de la base de donnes.

    NAME char(10) nom du fichier logique ou physique CREATOR char(10) propritaire du fichier TYPE char(1) type de fichier L=fichier Logique

  • DB2/400 les donnes et l'OS400 30

    Institut de Poly-informatique (1995)

    P=fichier Physique T=Table (SQL) V=Vue (SQL) COLCOUNT smallint nombre de champs du fichier RECLENGHT smallint longueur des enregistrements LABEL char(30) chane accessible par ordre SQL LABEL ON REMARKS char(254) commentaire DBNAME char(10) nom de la librairie contenant le fichier

    10.22

  • DB2/400 les donnes et l'OS400 31

    Institut de Poly-informatique (1995)

    10.23 SYSVIEWDEP Cette vue enregistre les dpendances des vues logiques sur les fichiers physiques.

    DNAME char(10) nom du fichier logique DCREATOR char(10) propritaire de la vue BNAME char(10) nom du fichier physique BCREATOR char(10) nom du propritaire du fichier physique BDBNAME char(10) nom de la librairie du fichier physique BTYPE char( 1) type de l'objet sur lequel la vue porte T=fichier physique V=vue logique

    10.24 SYSVIEWS Cette vue contient un ou plusieurs enregistrements pour chaque vue logique de la base de donnes. Chaque enregistrement contient les 70 premiers caractres de la commande de cration de la vue.

    NAME char(10) nom du fichier logique CREATOR char(10) propritaire de la vue SEQNO integer n d'ordre d'enregistrement dans la vue le premier tant 1 CHECK char(1) inutilis sur AS400, prsent pour assurer la compatibilit avec la norme SQL TEXT char(70) dbut de l'ordre SQL de cration de la vue.

  • DB2/400 les donnes et l'OS400 32

    Institut de Poly-informatique (1995)

    11 volutions relatives au support de DB2 en V3R1M0 11.1 Support de IFS (Integrated File System) IFS est une structure systme qui permet l'AS400 de supporter simultanment : - un systme de fichiers micro, - un systme de fichiers Unix, - le systme des bibliothques de l'OS400, - le systme de dossiers de bureau, - des systmes de fichier utilisateur personnaliss.

    Racine

    QDLS

    dossiers partags

    DB2 POSIX

    QSYSQOpenSys QLANSrv

    QPWXCWNWindows

    Unix LAN serverQFileSrvr.400 QOPT ToTo

    QIWSFLR2

    Myfolder

    Myrep Mydoc

    LIB

    FILE

    MEMBER MEMBER

    usr

    bin etc

    Home

    Serv1

    Serv2

    QPWXCRMRumba

    QPWXCPC5250

    Serv1

    serv2serveur

    optique

    serveuroptique

    rep1

    rep2

    fichierfichier

    11.2 Rorganisation des tables systme Pour supporter le niveau 2 de DRDA, les tables systme de l'OS400 ont t rorganises. Ainsi les tables SQL ne sont plus dans chaque collection mais dans QSYS. De plus un certain nombre de tables supplmentaires ont t ajoutes 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, ...

  • DB2/400 les donnes et l'OS400 33

    Institut de Poly-informatique (1995)

    11.5 QADBIFLD contient les informations relatives aux zones, comme type, longueur, etc ... 11.6 QADBKFLD contient les informations relatives aux cls des chemins d'accs, comme nom de la zone, sens du tri, ... 11.7 11.8 QADBXRDBD contient les informations relatives au rpertoire de la base de donnes rpartie, comme les noms des lieux loigns, les ID d'echange de rseau, ... 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 sytme SQL sont en ralit stockes dans QSYS2, leur nombre a galement augment.

    Nom de catalogue SQL contient les infos concernant SYSCOLUMNS attributs de colonnes SYSCST toutes les contraintes SYSCSTCOL colonnes rfrences dans une contrainte SYSCSTDEP dpendances des contraintes sur les tables index SYSINDEXES index, SYSKEYS cls d'index SYSKEYCST cls uniques, primaires et trangres SYSPACKAGE packages SYSREFCST contraintes d'intgrit rfrentielle SYSTABLES tables et vues SYSVIEW dfinitions de vues SYSVIEWDEP dpendances des vues sur les tables

    11.12 Support des contraintes d'intgrit rfrentielle L'intgrit rfrentielle permet de grer l'intgrit de la cohrence de la base de donnes l'extrieur des programmes. C'est un progrs considrable par rapport la base de donnes version 2.3.0. Mais il y a un revers. Tout systme applicatif possdant des fichiers et existant sur l'AS400 n'est pas ncessairement normalis. C'est dire que souvent la base de donnes applicative n'est en ralit pas une vraie base de donnes. C'est notamment souvent le cas dans des applications qui ont t dveloppes l'origine sur un systme 36.

  • DB2/400 les donnes et l'OS400 34

    Institut de Poly-informatique (1995)

    Pour mettre en oeuvre l'intgrit rfrentielle, il est indispensable, que la base de donnes satisfasse aux rgles des formes normales. Si ce n'est pas le cas, mieux vaut rester en l'tat. Si, donc votre base de donnes est normalise (vous avez donc utilis MERISE pour la concevoir), vos programmes vont se trouver algs d'un grand nombre de lignes de code maintenant inutiles. Avec l'intgrit rfrentielle, le gestionnaire de base de donnes peut seul et automatiquement gr les relations entre un fichier pre et un fichier fils. La rgle est que toute cl trangre non nulle doit obligatoirement avoir son quivalent en cl primaire dans le fichier pre. 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 mme 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 dfinie sur le fichier dpendant donc le fichier fils. Les contrles sont soit implicites (automatiques) en cas de cration ou de mise jour de cl associe, soit explicites en cas de suppression. Il faut alors indiquer la rgle de mise en oeuvre au paramtre DLTRULE. Les valeurs possibles sont : - *NOACTION suppression d'un record dans le pre interdit si au moins un record du fils fait rfrence cette cl. - *RESTRICT idem *noaction mais contrle immdiat avant la suppression du pre. - *CASCADE lorsqu'un record du pre est supprim, tous les records du fils contenant la mme valeur de cl sont supprims. - *SETNULL lorsqu'un record du pre 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 dfaut dfinie dans le fils qui est utilise. La diffrence 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 effectues avant que la contrainte soit lance. 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 opration prilleuse. Si par contre vous utilisez *RESTRICT, la vrification est lance avant les mises jour et le message intervient dans votre programme RPG sans que vous ayez faire une mise jour arrire. *RESTRICT donne donc de meilleures performances et doit tre prfr *NOACTION qui est pourtant la valeur par dfaut du paramtre. 11.13 Support des triggers ou dclencheurs

  • DB2/400 les donnes et l'OS400 35

    Institut de Poly-informatique (1995)

    Sur AS400 le dclencheur et le programme dclench 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 entirement laiss la discrtion du programmeur. il y a galement des rgles (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). Gnralement un trigger de record est utilis pour faire les contrles de zones du record. Ainsi vos programmes se trouvent dchargs du contrle 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. Nanmoins la fonction trigger est trs riche et permet de dfinir pour un seul record un trigger avant et aprs cration, mise jour et suppression. Six triggers diffrents peuvent donc tre dclenchs pour un mme record. Le programme dclench a obligatoirement deux paramtres d'entre qui sont une structure et la longueur de la structure.Le dessin de la structure est : - nom du fichier (fichier, bibliothque, membre) - type d'opration (cration, mise jour, suppression) - moment de l'appel (avant, aprs) - niveau de verrouillage - pointeur position et longueur (dans la structure) du buffer avant l'opration - pointeur position et longueur (dans la structure) du buffer aprs l'opration - valeurs du buffer avant - valeurs du buffer aprs 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'intgrit rfrentielle, les messages suivants sont mis : - CPF502D violation de CIR sur le membre &4 en ajout dans un fichier fils sans correspodance dans le fichier pre. - CPF503A violation de CIR sur le membre &4 en suppression du fichier pre alors qu'il existe des records du fichier fils faisant rfrence cette valeur de cl trangre. - CPF502E enregistrement verrouill, la CIR ne peut tre lance. - CPF523B erreur de CIR lors du traitement du membre &4 impossibilit systme.

  • DB2/400 les donnes et l'OS400 36

    Institut de Poly-informatique (1995)

    - CPF523C erreur dans le journal d'intgrit rfrentielle. les rgles demandent un contrle de validation, mais la journalisation n'est pas dmarre ou les rcepteurs de journaux des deux fichiers sont diffrents. 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 grer les messages escape en RPG grce aux APIs de messages. 11.16 11.17 11.18 Procdures catalogues Une implmentation de SQL pour mise niveau avec SQL2 permet DB2/400 de mettre en oeuvre les procdures catalogues. 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 paramtres. 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 donnes rparties mme en cas de rupture du rseau.

  • DB2/400 les donnes et l'OS400 37

    Institut de Poly-informatique (1995)

    12 Les fichiers de l'OS400 12.1 12.2 Types de fichiers L'OS400 supporte 4 types de fichiers. - fichiers de donnes (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 cls de recherche et les DSPF, PRTF, ICFF ne contiennent que des descriptions. Fichier PF comportant les donnes. Contient 3 parties :

    Fichier LF : Logical File

    Fichier BD dpendant d'un PF ou de plusieurs PF (max. 32) et servant crer : - un index sur les donnes du PF : un chemin d'accs aux donnes du PF. - un classement des donnes du PF : un tri pour une lecture squentielle. - une slection des donnes du PF : une vue slective des donnes. - un regroupement de donnes de plusieurs PF dans un mme fichier : logique joint. Contient 2 parties : ( pas de donnes dans un LF )

  • DB2/400 les donnes et l'OS400 38

    Institut de Poly-informatique (1995)

    LF

    PF

    Puisque manipuls 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 compile 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 systme, il existe en ralit 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 donnes. C'est

    que que nous pouvons appeler les membres. Cette dfinition nous permet de comprendre qu'un membre se comporte au moment des accs comme un fichier part entire avec ouverture, dbut, fin, fermeture. C'est la commande OVRDBF qui permet d'accder aux diffrents membres donc aux diffrents data spaces du mme fichier. dans un data space les enregistrements sont rangs par ordre d'arrive.

    - les index de data space qui permettent d'ordonner les enregistrements de data space

    autrement que dans l'ordre d'arrive. Le mcanisme d'ordonnancement des enregistrements est bas sur un algorithme d'arborescence dichotomique basale. C'est ce qu'on appelle en OS400 les chemins d'accs.

    - les curseurs sont des mcanismes de visualisation des donnes. Ils contiennent les

    mcanismes de slection et d'omission. C'est ce qui sert de base la fonction OPNQRYF de l'OS400 ou l'ouverture avec slection dynamique. Il est possible dans ces curseurs de raliser des fonctions de mapping qui permettent de voir les donnes sous d'autres formats que ceux stocks ou de crer des zones rsultantes d'oprations sur des zones existantes. Les ordres OPEN et CLOSE couramment utiliss en HLL dclenchent les instructions MI ACTIVATE CURSOR et DEACTIVATE CURSOR

    12.3 Accs aux fichiers L'OS400 considre tous ses priphriques (devices) comme des priphriques "bloc". C'est dire qu'il ne converse avec eux que par paquets d'octets et non octet par octet. Ainsi sur un

  • DB2/400 les donnes et l'OS400 39

    Institut de Poly-informatique (1995)

    cran par exemple il n'est pas possible d'adresser directement une ligne colonne et d'y inscrire un caractre. On ne pourra crire ou lire sur l'cran que la totalit de cet cran. De mme dans un fichier de donnes, on ne pourra accder qu' un enregistrement et pas un caractre unique. L'accs physique dpend avant tout de la capacit d'entre sortie de chaque appareil. Dans la ralit, un lecteur de diskette pourra lire ou crire 128, 256, 512 octets la fois. Un lecteur de disque dur pourra accder 512, 1024, 2048, 4096 octets la fois. Un contrleur d'cran pourra grer 1920 ou 2000 octets la fois. Les lectures et critures se feront par block du nombre d'octets grables par l'appareil considr. Pourtant il arrive souvent qu'on ne dsire pas accder un nombre aussi important d'octets. Il y a donc un accs logique pour l'utilisateur qui est diffrent de l'accs physique de la machine. Il faut donc utiliser un intermdiaire qui permettra le dcoupage logique des donnes physiquement prsentes. Cet intermdiaire est appel un tampon (buffer). Les donnes en entre ou en sortie seront stockes 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 dsirera lire un enregistrement de 128 octets, on accdera en ralit 32 enregistrements de ce fichier sur le disque. Si on rcrit 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 mmoire. Si la lecture suivante fait appel un des 31 autres enregistrements contenus dans le buffer physique, il n' y aura pas d'accs disque en lecture. Il n'y aura que transfert mmoire 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 dcrire au systme la taille du buffer logique du fichier que l'on dsire utiliser, pour permettre les accs. Sur AS400 cette opration s'appelle DDS (data description specification). Les descriptions de fichiers seront entres dans des spcifications sources de type A dont vous pouvez voir un exemple en annexes. 12.4 CONTRLE DES ACCS FICHIERS D'une faon gnrale le contrle des accs aux fichiers est laiss la charge du systme d'exploitation. Celui-ci ne communiquant aux programmes qui dsirent accder ces fichiers que des codes retour renseignant sur l'issue de la dernire opration effectue (opration

  • DB2/400 les donnes et l'OS400 40

    Institut de Poly-informatique (1995)

    russie ou non et si non pour quel motif. L'OS/400 donne au programmeur la possibilit d'accder de nombreuses informations sur les fichiers accds. Deux zones de contrle fichier sont disponibles, aprs une opration russie d'ouverture sur un fichier. Il s'agit de l' open feedback area et de l'I/O feedback area. Ces zones de contrle peuvent se rvler trs utiles lorsqu' une erreur se produit sur un fichier. 12.4.1 Open feedback area Cette zone contient des informations d'ordre gnral sur le fichier comme son nom, la librairie, le type etc ... 12.4.2 I/O feedback area Cette zone est dcoupe en deux parties. La premire commune tous les types de fichiers d'une longueur de 143 octets et donnant des renseignements comme des compteurs d'oprations d'entre sortie par type d'opration, la nature de l'opration en cours, le nom du format d'enregistrement en cours, le type de priphrique utilis, etc ... La deuxime tant en fonction du type de fichier. Une description dtaille des diffrentes I/O feedback est donne dans des membres de LIBUXX/YYY,YYYMIxF (x =G[LF],.=D[DSPF], =P[PRTF]).

  • DB2/400 les donnes et l'OS400 41

    Institut de Poly-informatique (1995)

    13 Les fichiers de donnes 13.1 Structure La structure des fichiers de donnes peut tre shmatise selon l'exemple suivant :

    14 Description Une description de spcifications de donnes est enregistre dans un fichier source. Les zones dcrites dans une DDS sont les plus petits lments physiques et logiques accessibles par l'OS400. Il n'est pas possible d'appliquer un tampon logique diffrent du tampon physique sur une zone de la base de donnes AS400. Un dcoupage logique d'une zone de la base de donnes ne sera possible qu' l'intrieur d'un programme par l'intermdiaire d'une structure de donnes. La description externe des fichiers, garantie l'indpendance des donnes 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 spcifiques qui permettent d'apporter des prcisions sur la description. 14.1 fichiers physiques Le fichier physique de donnes est le type d'objet OS400 qui contient effectivement les donnes utilisateurs. Nous verrons un peu plus loin que les fichiers logiques ne contiendrons que les chemins d'accs ces donnes de fichiers physiques.

  • DB2/400 les donnes et l'OS400 42

    Institut de Poly-informatique (1995)

    14.2 Structure Un fichier physique de donnes est constitu : - D'un format qui est la version compile de la description de fichier. - D'un chemin d'accs qui est la faon d'accder aux enregistrements du fichier. Le chemin d'accs peut tre par ordre d'arrive c'est dire sans organisation particulire 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 recommande. Il peut tre par index si une ou plusieurs zones de la description d'enregistrement ont t renseignes comme cl (K). Dans ce cas le chemin d'accs existe physiquement et est organis sous forme d'arbre binaire afin d'en faciliter le traitement. Cette forme n'est pas recommande car elle offre peut de scurit contre une destruction du fichier par maladresse. - Des donnes regroupes ventuellement par membres distincts. L'accs par dfaut tant sur le 1 er membre. Pour accder un autre membre, il sera ncessaire de recourir la commande OVRDBF

  • DB2/400 les donnes et l'OS400 43

    Institut de Poly-informatique (1995)

    15 Mots cl 15.1 Niveau fichier ALTSEQ Dfinition : ALTSEQ (nom bibliothque/nom table) nom bibliothque EST OPTIONNEL Il classe les enregistrements en utilisant une table de remplacement contenant une squence de classement pour la cl. Autrement dit, le fichier peut tre tri sur la cl, si ALTSEQ est mentionn et qu'une squence de classement est spcifie pour la cl. Pour cela, il utilise une table. FIFO (premier entr, premier sorti) On utilise ce mot cl pour prciser 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 paramtre. On ne peut pas l'utiliser avec les mots cl LIFO, UNIQUE et REAFACCPTH. Si ni FIFO, ni LIFO ou ni UNIQUE ne sont spcifis, 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 spcifie dans le fichier qui contient le mot cl FIFO. FIFO n'est pas valide si l'on prcise un type de fichier *CSRC sur une commande de cration de fichier logique. LIFO On utilise ce mot cl pour prciser que les enregistrements rcuprs 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 spcifis,les enregistrements sont rcuprs soit dans l'ordre: PREMIER-ENTRE / PREMIER-SORTI, soit DERNIER-ENTRE / PREMIER-SORTI. Mais l'ordre dans lequel on rcupre les enregistrements n'est pas garanti. Au moins un champ cl doit tre prcis dans le fichier qui contient le mot cl LIFO. Ce mot cl n'est pas valide lorsque l'on prcise un type de fichier (*SRC) sur la commande de cration d'un fichier logique.

  • DB2/400 les donnes et l'OS400 44

    Institut de Poly-informatique (1995)

    REFSHIFT Mot cl de niveau fichier utilis pour contrler l'accs 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 associes 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 prciser le nom du fichier duquel les descriptions sont tires. Son format est : REF( Biblio./Fichier de donnes (nom du format d'enregistremt)) Pour prciser 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. ************** Dbut des donnes ************************ 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 donnes ************************* UNIQUE Ce mot cl n'a pas de paramtres. On utilise ce mot cl pour spcifier que des enregistrements diffrents avec des valeurs de cl identiques ne sont pas autoriss dans un membre du fichier physique. Aucune addition ou mise jour dans une cl en double n'est accepte. Le programme d'application faisant l'criture ou l'opration de mise jour reoit un message d'erreur, de mme qu'un programme DFU. Une commande de copie de fichier qui copierait des enregistrements avec des cls 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 cls en double. Quand on prcise le mot cl UNIQUE pour un fichier physique, on doit prciser la valeur de paramtre MAINT (*IMMED) sur la commande de cration de fichier (CRTPF) pour crer le fichier. Cela signifie que le chemin d'accs est mis jour immdiatement au fur et mesure des changements.

  • DB2/400 les donnes et l'OS400 45

    Institut de Poly-informatique (1995)

    Quand le mot cl UNIQUE n'est pas prcis, les enregistrements avec des valeurs de cls en double sont rangs soit dans l'ordre premier entr - premier sorti, soit dernier entr - premier sorti. Si on ne prcise pas le mot cl UNIQUE, ni FIFO, ni LIFO, par dfaut les enregistrements seront traits en FIFO. Le mot cl UNIQUE ne peut pas tre utilis en mme temps que FIFO, LIFO, ou REFACCEPTH. FMT LF A..........T.Name++++++.Len++TDpB Functions++++++++ ************** Dbut des donnes ************************** 0001.00 A UNIQUE 0002.00 A R ARTENR PFILE(ARTP) 0003.00 A K ARTCOD *************** Fin des donnes *************************** 15.2 Niveau format d'enregistrement FORMAT Le mot cl FORMAT sert rutiliser dans un autre fichier ( exemple fichier n2) des champs identiques, au fichier d'origine ( exemple fichier n1 ). On utilise ce mot cl de niveau format pour prciser que ce format aura les mmes spcifications de champs, qu'un niveau format prcdemment dfini. 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 spcifie pas le nom de la librairie, la liste des librairies (*LIBL) active au moment de la cration, est utilise. Certaines restrictions existent quand l'utilisation du mot cl FORMAT : - Ne pas spcifier les spcifications des champs, pour ce niveau de format. Spcifier les spcifications des cls, si vous voulez quelles soient actives pour ce fichier ( elles peuvent tre les mmes ou bien diffrentes, que le niveau de format prcdemment dfini). - On ne peut spcifier 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 spcifications du RECORD dans le fichier 1. Les deux fichiers ont t crs. Si le fichier 1 est

  • DB2/400 les donnes et l'OS400 46

    Institut de Poly-informatique (1995)

    supprim, puis recr avec diffrents DDS ( Data Description Specification ), RECORD reste existant dans le fichier 2. Il peut tre rfrenc partir du niveau de format originel, par d'autres fichiers utilisant le mot cl FORMAT.

  • DB2/400 les donnes et l'OS400 47

    Institut de Poly-informatique (1995)

    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 suprieure 6 ; comprise entre 1 et 30 et commenant obligatoirement par une lettre. Les caractres suivant peuvent tre soit des chiffres, soit des lettres soit le trait bas(_)(trs utilis pour les applications dveloppes 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 diffrent d'un autre, ainsi que d'un nom de champ dfini 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 rfrence. Lorsque ce mot cl est indiqu, la longueur du champ en vis vis ne doit pas dpasser 32765 caractres. CHECK Ce mot cl attribue un contrle de validit au niveau du CHAMP dans un fichier cran. Il n'intervient pas directement dans les fichiers physiques. Les codes utiliss pour 'CHECK' sont : - CHECK AB (allow blank) :zone blanc autorise, - CHECK ME (mandatory enter):frappe obligatoire, - CHECK MF (mandatory fill) :zone complte si frappe, - CHECK M10 :contrle modulo 10, - CHECK M11 :contrle modulo 11, - CHECK VN (valid name) :contenu zone doit tre un nom valide, - CHECK VNE(valid name extend). Le contrle se fait par un chiffre de contrle permettant de vrifier la validit des donnes. Ce chiffre est le rsultat d'un calcul effectu sur les autres chiffres. Vous ne pouvez pas utiliser CHECK AB, VN, VNE, M10, M11 pour un champ dfini en virgule flottante. CMP Ce mot cl est quivalent au mot cl COMP

  • DB2/400 les donnes et l'OS400 48

    Institut de Poly-informatique (1995)

    Le format est : CMP(oprateur relationnel, valeur) Le mot cl COMP est prfr - 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 spcifier la vrification de validit, aux champs que vous dfinissez lorsqu'il sera rfrenc ultrieurement lors de la cration d'un fichier cran ou la cration d'applications DFU. La syntaxe est: COMP(oprateur relationnel- valeur) Quand l'on dfinit dans un fichier cran un champ au type zone en entre (input) rfrencez le champ que vous tes en train de dfinir 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 contrle de validit (validity-checking) en les spcifiant pour le champ dans le fichier cran. (voir "rfrencer, position 29" dans la page 4-9. Il ne faut pas spcifier le mot cl dans un champ de type flottant "F dans la position 35. Les rgles pour spcifier ce mot-cl dans un fichier physique sont les mmes que pour un fichier cran. "voir COMP (comparaison) la page 4-75 pour pour connatre 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 caractres chacune est autoris. FMT PF A..........T.Name++++++ RLen++TDpB Functions+++++++++++++++ ************** Dbut des donnes ********************************* 0001.00 A R REPENR 0002.00 A* 0003.00 A* Client 0004.00 A CLINBR 5 0 TEXT('Code client . . . 0005.00 A COLHDG('NCLI.') 0006.00 A CLIRAI 40 TEXT('Nom du client . . 0007.00 A COLHDG('NOM DU CLIENT') 0008.00 A CLIRUE 40 TEXT('N et rue . . . . 0009.00 A COLHDG('N ET RUE')

  • DB2/400 les donnes et l'OS400 49

    Institut de Poly-informatique (1995)

    0010.00 A CLICMP 40 TEXT('Complment d''adresse') Utilisez ce mot cl de niveau champ afin de spcifier l'entte de colonne utilise pour ce champ pour la gestion de texte, l'utilitaire QUERY, l'utilitaire de fichiers de donnes (DFU) et l'utilitaire d'aide de conception d'cran (SDA). Chaque ligne d'entte de colonne doit tre entoure d'apostrophes .Utilisez l'apostrophe double pour spcifier l'apostrophe l'intrieur d'une entte de colonne. Si vous ne spcifiez pas COLHDG et que le champ rfrenc n'est pas rcupr d'un champ rfrenc, le nom du champ est utilis. Si vous spcifiez COLHDG et ne spcifiez pas texte, 50 positions d'information d'entte de colonne sont utilisables en tant que texte. Par exemple TEXTE ('ORDER DATE') est construit par OS/400 quand ((when the field spcifies COLHDG ('order''date') but no text keyword) montre comment spcifier le mot cl COLHDG. L'exemple suivant montre comment apparat le texte du mot cl lorsqu'il est gr par text managment, query, dfu, ou SDA. CUSTOMER ORDER CITY DATE CUSTOMER'S NAME FIELD NNNN XXXXXXXXXXXXXXXXXX XXXXXXXXXXXX CSSID Ce mot cl est utilis au niveau zone, mais peu aussi tre aussi utilis au niveau record ou fichier. Au niveau zone il est utilis pour une zone dclare en type G graphique pour prciser que ce champ est de type UCS-2 (unicode). Le format est : CSSID(UCS2-numro) Numro est une valeur comprise entre X7200 et X72FF et est un numro 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 dfaut est *ISO.

  • DB2/400 les donnes et l'OS400 50

    Institut de Poly-informatique (1995)

    DFT Utiliser le mot cl niveau zone DFT pour spcifier une valeur par dfaut pour un champ. Le format est : DFT('valeur') ou (X 'valeur') o X = 'valeur hexadcimale' Les valeurs constantes peuvent tre : Une valeur caractre dans laquelle chaque caractre est imprim selon la spcification. Le nombre de caractres est gale la longueur imprime du champ. Une valeur hexadcimale, dans laquelle deux caractres identifient un code dans le jeux de caractres. Ces caractres s'impriment dans ce champ. Les indicateurs ne sont pas valides pour ce mot cl. Cependant ils peuvent tre utiliss pour conditionner le champ constant avec lequel ce mot cl est spcifi, en prcisant l'indicateur sur la mme ligne o le champ est spcifi.(voir doc DDS Rfrence 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 hexadcimale est spcifie pour le mot cl DFT. EDTCDE et EDTWRD Ces mots cl sont utiliss pour indiquer comment se fera l'affichage ou l'impression de la zone en vis vis. Celle-ci est une zone numrique. Ce mot cl n'a pas de rpercussion directe pour le fichier physique. 0000.40 A R ECR010 0000.50 A* 0000.60 A 1 2DATE 0000.70 A EDTCDE(Y) 0013.70 A QMTART 5Y 0B 8 27EDTCDE(Z) 0014.30 A 9 2'Prix unitaire H.T. . . .' 0014.40 A PRUART 7Y 2B 9 27EDTWRD(' , ') FLTPCN VIRGULE FLOTTANTE Ce mot cl de niveau champ spcifie la prcision de la virgule flottante pour une zone numrique. Le format est: FLTPCN(*single/*double) Le paramtre indique si la zone est en simple ou double prcision. Ce mot-cl est seulement valide pour un champ en virgule flottante.

  • DB2/400 les donnes et l'OS400 51

    Institut de Poly-informatique (1995)

    Le mot cl est par dfaut en simple prcision. Dans un champs en simple prcision on peut avoir jusqu' 9 positions maximum et en double prcision on peut avoir jusqu' 17 positions maximum. Si le champs spcifi dpasse 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 spcifier un contrle de validit sur la zone que vous dfinissez lorsqu'elle sera rfrence pendant la cration d'un fichier cran ou la cration d'une application DFU. RANGE ne modifie pas le fichier physique que vous avez dfini. Quand vous dfinissez une zone d'entre dans un fichier cran, rfrencez la zone en spcifiant 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 contrle de validit en les spcifiant pour la zone dans le fichier cran. Les donnes entres doivent tre suprieures ou gales la valeur minimale et infrieures ou gales la valeur maximale. Quand la zone est de type caractre, les valeurs du paramtre doivent tre entre apostrophes. Quand la zone est numrique, les apostrophes ne doivent pas tre spcifies. Les indicateurs d'option ne sont pas valides pour ce mot-cl. La donne entre dans une zone numrique est aligne sur le nombre de dcimales spcifies en colonnes 36 37, les blancs de dbut et/ou de fin sont remplis avec des zros. Ne pas spcifier le mot-cl RANGE pour une zone en virgule flottante (F en position 35). Les rgles pour spcifier ce mot-cl dans un fichier physique sont les mmes que pour un fichier cran. Voir RANGE la page 4-182 pour plus d'informations, ainsi que pour un exemple montrant comment spcifier ce mot-cl. REFFLD Le format est : REFFLD ((nom du format d'enregistrement/)nom du champ rfrenc ((*SRC ou biblio/fichier de donnes))) Mot cl de niveau fichier utils pour rferencer un champ sous 3 conditions : - quand le nom du champ rferenc est different du nom se trouvant dans les positions entre 19 et 28,

  • DB2/400 les donnes et l'OS400 52

    Institut de Poly-informatique (1995)

    - quand le nom du champ rferenc est le meme que celui se trouvant dans les positions entre 19 et 28 mais que le format d'enregistrement, le fichier ou la bibliothque du champ rfrenc est different de celui prcis avec REF, - quand le champ rferenc se trouve dans le mme fichier source DDS que le champ de rfrence. 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 caractres. Au cas ou plus de 50 caractres sont spcifis, le mot cl est accept. Toutefois, les caractres supplmentaires ne sont pas pris en compte. Si TEXT n'est pas spcifi et que le mot cl COLHDG est prcis, 50 positions sont utilises par dfaut. Si l'on ne prcise pas COLDHG et que le champ n'est pas concatn, le texte est pris dans le champ physique TEXT s'il existe. Si l'on ne prcise pas COLDHG et que le champ est concatn, Il n'y a pas de texte. NB : L'on peut prciser TEXT aussi bien au niveau enregistrement qu'au niveau champ. On peut prciser 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 vrification du champ que vous avez dfini quand il est rfrenc plus tard lors de la cration du fichier cran ou aprs la cration d'une application dans DFU. VALUES n'affecte pas le fichier physique que vous avez dfini. Mais quand vous dfinissez un champ de saisie dans un fichier cran vous pouvez rfrencer le champ que vous avez dfini (en spcifiant R en position 29 et REF ou REFFLD mot cl). Pendant la cration 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, vrifier, valider ce mot cl en le spcifiant pour le champ dans le fichier cran. Voir "REF (rference) page 4-183 pour plus de dtails". Vous ne pouvez pas spcifier le mot cl values dans un champ dcimal l ou il y a une virgule flottante (il faut mettre F dans la colonne 35) les rgles de spcification du mot cl VALUES dans un fichier physique sont les mmes que pour le fichier cran.

  • DB2/400 les donnes et l'OS400