Blog ENI : Toute la veille numérique !
🐠 -25€ dès 75€ 
+ 7 jours d'accès à la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. RPG et CL
  3. Les fichiers
Extrait - RPG et CL Maîtrisez la programmation sur AS/400
Extraits du livre
RPG et CL Maîtrisez la programmation sur AS/400
1 avis
Revenir à la page d'achat du livre

Les fichiers

Introduction

Dans un certain sens, tout objet AS/400 est un fichier, que ce soit un programme, un fichier de données ou un écran, tout est écrit quelque part dans l’espace mémoire des disques durs. Mais tous les objets ne sont pas de type *FILE. Seuls les fichiers source (attribut SRC), les fichiers de données (attribut PF-DATA), les logiques (attribut LF), les écrans (attribut DSPF) et les fichiers d’impression (attribut PRTF) sont des objets de ce type.

Tout d’abord les limites, elles existent mais on les atteint assez rarement :

  • Nombre d’octets par enregistrement : 32 766

  • Nombre de champs par format : 8 000

  • Nombre de zones clé dans un fichier : 120

  • Taille de la clé d’un fichier PF ou LF : 2 000 caractères

  • Nombre d’enregistrements dans un membre : 2 147 483 646 (*NOMAX)

  • Taille d’une zone caractère : 32 766

  • Taille d’une zone (décimal ou condensé) : 31 digits

  • Nombre maximal de membres : 32 766 (*NOMAX)

  • Nombre de triggers par fichier PF : 6

Pour la taille d’un nombre, prononcer 9 999 999 999 999 999 999 999 999 999 999, pour savoir combien cela fait au juste.

Et les principales commandes utiles pour les fichiers :

  • DSPFD : description générale du fichier et de son contenu.

  • DSPFFD : liste des champs.

  • DSPPFM : visualisation "à plat", les zones numériques ne sont pas toujours lisibles.

  • DSPDBR : liste des logiques...

Création d’un fichier source

Les fichiers de type source sont utilisés pour stocker des données à compiler : programmes, écrans, fichiers d’impression et autres.

Leur principale caractéristique est qu’ils comportent toujours trois zones. La première est un numéro de séquence qui comporte 9 chiffres dont deux décimales. Cette zone est utilisée afin de mettre dans l’ordre convenable les séquences d’instructions. La deuxième est une zone d’audit comportant la date et l’heure de mise à jour. La dernière contient les données (code RPG, instructions CL, etc.).

La longueur par défaut est de 80 caractères, affichage standard AS/400, mais rien n’interdit de faire plus long.

L’autre caractéristique de ces fichiers est qu’ils sont, le plus souvent, multimembres.

Par exemple le fichier QCLSRC, par défaut il en existe un dans la bibliothèque QGPL, mais il est fortement déconseillé de l’utiliser, sauf de façon temporaire… ou par accident.

Dans ce fichier, on trouvera autant de membres qu’il y a de sources CL. Chaque membre portera le nom de l’objet qui sera généré lors de la compilation. De la même façon, on trouvera un fichier QRPGSRC pour les programmes RPG.

La création d’un fichier source se fait, en général, par l’appel de la commande CRTPF (créer un fichier physique), mais pour les fichiers CL ou RPG, on ne créera que le membre portant le nom du programme. Ces fichiers sont connus du système, comme tous les objets dont le nom commence par un Q, et, lorsqu’on ouvre ces fichiers par l’éditeur...

Accès au fichier

Auparavant nous avons saisi la commande STRPDM qui appelle l’écran suivant.

Il est temps de voir un peu plus en détail de quoi il en retourne.

L’option 1 a été utilisée précédemment pour visualiser nos bibliothèques, pas besoin d’y revenir, d’autant que ce n’est pas le choix le plus utilisé.

04ep02.png

L’option 2 sera utilisée lorsque les premiers objets seront compilés. Pour le moment, en saisissant le nom d’une de nos bibliothèques on ne verra rien sauf pour la bibliothèque TBIBSRC.

Il y a quand même une supercherie, car le type d’objet fait au maximum 8 caractères, alors que la zone de saisie en compte 10.

04ep03.png

Si tout c’est bien passé l’écran suivant devait être ainsi.

04ep04.png

Si ce n’est pas le cas, il ne reste plus qu’à vérifier où sont passés les objets manquants. La commande WRKOBJ *ALLUSR/QCLSRC par exemple est d’un grand secours et il y a de fortes chances de retrouver ses fichiers dans QGPL

À ce stade, seule l’option 12 donnera un résultat probant en ce sens que l’on verra les membres du fichier, c’est-à-dire rien. Les autres options seront le plus souvent inutilisables ou, au mieux donneront des informations sur le fichier, son propriétaire, comment il a été créé...

L’exercice du jour

En résumé

Les fichiers source contiennent dans la majorité des cas des programmes, des fichiers et, plus généralement, la description d’objets à compiler. Plus rarement, et pour des raisons techniques, des données temporaires ou non à usage particulier.

Pour vous entraîner, créez un fichier source pour des programmes de type REXX, le nom du fichier sera QREXSRC. Le membre contenant le source se nommera PGRX01, par exemple et il contiendra :

0001.00 SAY "Bonjour. Saisis ton nom petit homme." 
0002.00 PULL who
0003.00 IF who = " " THEN SAY "Tu ne veux pas me dire qui tu es ?"
0004.00 ELSE SAY "Bonjour" who"." "tu as demandé que j'éteigne la machine ?"
0005.00 SAY "Extinction en cours. Pour annuler taper 8629253" 

Et pour voir le résultat, faire 16 devant le source.

Un petit complément, on peut lancer des commandes ou des programmes.

Ce type de programme est assez rarement utilisé, mais cela existe, et, c’est un des rares cas de programme interprété sur AS/400, il fallait donc bien en parler.