La base de données DB2/400
Introduction
La dénomination officielle selon IBM est DB2 UDB (Universal Data Base). On peut trouver la dénomination "universel" un peu prétentieuse, mais de fait on peut y stocker à peu près tout ce dont on a besoin et, surtout, le retrouver assez facilement dans des délais assez raisonnables.
Pour utiliser les données contenues dans un fichier, la bibliothèque dans laquelle se trouve le fichier doit être dans la *LIBL du travail en cours.
Ce détail, qui semble anodin, est en fait très important car, lors de l’exécution d’un programme et il est bien rare qu’un programme (RPG) n’ouvre pas un seul fichier, si le JOB a la même *LIBL que précédemment, il se plantera dès le démarrage pour cause de fichier non trouvé.
Les fichiers physiques et logiques (PF/LF)
Un fichier physique peut exister seul, en revanche il ne peut y avoir de fichier logique qui ne soit rattaché à un physique, l’AS/400 l’interdit. Nous verrons plus en détail les pièges à éviter du fait de cette contrainte qui est plutôt… logique.
1. Les DTAARA
C’est le plus simple des fichiers de données. Dans la majorité des cas cette zone de données est destinée à stocker divers éléments liés à un environnement particulier. Supposons que nous ayons à gérer plusieurs sociétés ayant chacune leur fichier du personnel dans une bibliothèque spécifique, et il y aura sans doute pas mal d’autres fichiers. Nous aurons trois bibliothèques de données PBIBSOC1, PBIBSOC2 et PBIBSOC3 et les programmes de gestion seront dans une bibliothèque commune.
Comment faire pour que les utilisateurs de chaque société ne voient que ce qui leur est propre ?
Une des solutions consiste à mettre dans une bibliothèque commune une DTAARA par environnement, on les appellera SOC1, SOC2 et SOC3.
Dans chaque DTAARA on mettra le nom de la bibliothèque correspondant à l’utilisateur.
Lorsque l’utilisateur tape la commande CMDSOC SOC1, le premier programme appelé par cette commande ira lire dans la DTAARA SOC1 la bibliothèque à utiliser et la rajoutera en début de la *LIBL afin que la suite des opérations ne concerne plus que les données contenues dans cette bibliothèque. Il suffit à la fin de retirer la bibliothèque et, si l’utilisateur doit aller travailler sur SOC2, de refaire la même opération.
La commande CMDSOC est la commande qui permet d’utiliser le logiciel de gestion et SOC1 est le paramètre qui permet de savoir dans quel contexte il va travailler.
Dans la réalité, la DTAARA ne contiendra sans doute pas que le nom de la bibliothèque mais un bon nombre de paramètres permettant d’avoir tout le nécessaire pour travailler.
Nous n’utiliserons pas cette possibilité dans les programmes à venir, mais il serait assez simple de s’en servir. De nombreux logiciels font ainsi.
Dans la pratique, la commande CRTDTAARA permet de créer...
Rappels et conseils
Ce chapitre mérite quelques rappels et conseils.
Tout d’abord en ce qui concerne le nom des fichiers.
FIC00P = fichier physique (le suffixe P en témoigne)
FIC01L = fichier logique 1 (suffixe L, le 1 évoque l’unicité de la clé)
FIC02L, FIC03L = autant que nécessaire.
La partie FIC peut aller jusqu’à 7 caractères, mais en pratique il vaut mieux éviter de dépasser 5, ce qui fait un nom sur 8 caractères.
L’avantage de cette dénomination est qu’elle facilite la copie et évite la suppression sans sommation.
En ce qui concerne les logiques, éviter les noms farfelus qui ne font que brouiller les pistes, même si au départ cela partait d’un bon sentiment.
Ne jamais oublier que, sauf fichiers particuliers, il vaut toujours mieux déclarer un logique avec clé unique et de préférence un seul. Cela ne change rien aux précautions à prendre lors de la programmation, mais cela évite des dommages collatéraux plus graves et parfois plus insidieux.
Ne pas oublier qu’en cas de clé non unique, la lecture sur cette clé se fera, par défaut, sur des critères assez mystérieux. Par défaut le plus ancien sera le premier lu.
Pour les noms des zones de fichier, j’applique une recette personnelle qui vaut ce qu’elle vaut, mais...